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FOREWORD 


This  is  Volume  III  of  the  User's  Manual  Component  of  the  Integrated 
Nuclear  and  Conventional  Theater  Warfare  Simulation  (INWARS)  documenta¬ 
tion.  It  discusses  the  form  and  content  of  user  inputs  to  the  INWARS 

treatment  of  Echelon  Above  Division  Command,  Control,  and  Intelligence 
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CHAPTER  I 

INTRODUCTION  AND  OVERVIEW 


This  volume  of  the  INWARS  User's  Manual  describes  the  inputs  used  in 

2  p 

the  Command,  Control,  and  Intelligence  (C  I)  activities  of  INWARS  Cl 

V—  ~ 

elements  at  Echelons  Above  Division  (EAD).  In  essence,  these  inputs 

characterize  the  doctrines,  policies,  and  parameters  used  by  the^EAD0 Cyl 

elements  in  their  information,  decision,  planning,  and  control  processes.  <f~ 

The  inputs  are  accordingly  concentrated  in  the  "Fundamental  Knowledge" 

2 

portion  of  the  C  I  elements'  respective  Understandings  of  the  Situation 

2 

(UOS's)  presented  in  Figure  1-1.  In  fact,  the  C  I  input  procedures  can  be 

2 

characterized  as  procedures  to  create  a  UOS  for  each  EAD  C  l  element  and 
load  it  with  certain  basic  information. 


A.  STRUCTURE  OF  C2I  INPUT  PROCEDURES 

2 

The  mechanism  by  which  EAD  C  I  inputs  are  made  is  a  User-Oriented 

|  Input  Language  (or  UOIL).  Besides  facilitating  the  input  of  specific 

2 

values  to  specific  Cl  information  elements,  the  UOIL  enables  the  user  to 

easily  establish  relationships  among  different  information  blocks  and 

structures.  As  will  become  apparent  over  the  sequel,  this  latter  attribute 

is  extremely  important  to  the  Cl  inputs  due  to  the  varied  relationships 

and  linkages  among  structures  within  the  UOS. 

2 

In  broad  terms.  Cl  information  elements  are  structured  into  certain 

"blocks"  or  "records."  Blocks  are  then  related  to  one  another  by  access 

2 

references  or  pointers  stored  in  the  related  blocks.  A  common  Cl  infor¬ 
mation  structure  is  a  directory  of  linked  lists  of  certain  types  of  infor¬ 
mation  blocks.  Figure  1-2  portrays  an  example  of  such  a  structure  which 
will  be  used  for  illustrative  purposes  in  this  introduction. 

Also  in  broad  terms,  the  C^I  portion  of  the  INWARS  UOIL  can  be 
regarded  as  consisting  cf  two  basic  types  of  statements:  (1)  input  control 
statements,  and,  (2)  input  value  statements.  Input  control  statements 
concern  what  types  of  block  inputs  are  about  to  be  received  and/or  how 


Figure  1-1.  Structure  of  C£I  Element  Understanding 

of  the  Situation  (UOS) 
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those  blocks  are  to  be  accessed  (i.e.,  where  access  references--pointers-- 
to  them  are  to  be  stored).  By  contrast,  input  value  statements  cause 
specific  input  values  to  be  assigned  to  specific  information  elements  in  a 
given  block.  In  effect,  then,  input  control  statements  invoke  routines  to 
process  input  value  statements  for  given  types  of  information  blocks. 

Certain  input  control  statements  can  be  repeated  or  "nested"  under 
other  input  control  statements.  This  permits  complex  information  struc¬ 
tures  involving  many  interlinked  information  blocks  to  be  input  in  a  direct 
and  self-documenting  fashion.  This  can  be  illustrated  with  the  aid  of  the 
simple  directory  example  portrayed  in  Figure  1-2.  A  characteristic  input 
approach  would  involve  three  distinct  types  of  input  control  statements, 
e.g. ,  'DIRECTORY',  'ABLOCK',  and  'BBLOCK'.  The  "grammar"  of  these  control 
statements  would  recognize  sequences  consisting  of:  (1)  a  single  instance 
of  'DIRECTORY1,  followed  by  (2)  an  arbitrary  number  of  instances  of 
'ABLOCK',  followed  by  (3)  an  arbitrary  numbe**  of  instances  of  ‘BBLOCK1.  Of 
course,  each  instance  of  ‘ABLOCK1  or  'BBLOCK'  would  typically  be  followed 
by  an  appropriate  set  of  input  value  statements  to  insert  into  the  blocks. 
Figure  1-3  illustrates  a  typical  case. 

In  the  case  exemplified  by  Figure  1-3,  the  instance  of  'DIRECTORY' 
would  create  a  directory  block.  Each  subsequent  instance  of  'ABLOCK'  would 
create  an  ABLOCK  and  link  it  into  LIST1  in  the  directory  block  (and  insert 
specific  values  as  specified  in  the  corresponding  input  value  statements). 
Likewise,  each  subsequent  instance  of  'BBLOCK'  would  create  a  BBLOCK  and 
link  it  into  LIST2  in  the  directory  block.  The  result  of  the  example  would 
be  a  single  directory  containing  a  list  of  two  ABLOCKs  and  a  list  of  three 
BBLOCKs. 

B.  UOIL  PRESENTATION  CONVENTIONS 

2 

To  present  the  Cl  UOIL,  the  input  control  statements,  their  grammar, 

and  the  input  value  statements  must  be  described.  The  approach  taken  in 

2 

this  volume  follows  the  "flow"  of  the  C  I  UOIL.  Input  control  statements 
are  introduced  in  the  order  in  which  they  would  be  used  in  a  "typical" 
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DIRECTORY 

ABLOCK 

(ABLOCK  INPUT  VALUE  STATEMENT) 
ABLOCK 

(ABLOCK  INPUT  VALUE  STATEMENT) 
BBLOCK 

(BBLOCK  INPUT  VALUE  STATEMENT) 

i 

BBLOCK 

(BBLOCK  INPUT  VALUE  STATEMENT) 
BBLOCK 

(BBLOCK  INPUT  VALUE  STATEMENT) 

t 


Figure  1-3.  Typical  Case  of  Directory  Input 
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input.  Likewise,  when  an  input  control  statement  would  be  followed  by 
input  value  statements,  the  information  block  to  be  "filled"  is  introduced 
and  information  elements  to  be  input  are  described. 

To  facilitate  the  presentation  and  eliminate  the  need  for  repetitious 
detail,  it  is  convenient  to  adopt  certain  formats  and  conventions  for  use 
in  the  descriptions.  These  conventions  are  described  in  this  section. 

1.  General  Conventions 

The  so-called  Backus  Normal  Form  (BNF)  notation  for  describing 
grammatical  aspects  of  a  language  has  been  generally  adopted  as  will  now  be 
discussed. 

a.  String  Notation 

2 

Explicit  strings  to  be  used  in  the  C  l  UOIL  statements  are 
presented  in  capital  letters.  Implicit  strings  are  also  presented  in  capi¬ 
tals,  but  are  enclosed  with  double  bars  ('ll1).  An  example  illustrating 
both  notations  is: 

'DIRECTORY  =  ||  NAME 1 1  a 

This  description  characterizes  a  string  consisting  of  the  explicit  string 
'DIRECTORY  =  '  followed  by  an  implicit  arbitrary  string  being  used  as  a 
name. 

b.  Descriptors 

It  is  convenient  to  be  able  to  utilize  a  descriptor  which 
can  stand  for  any  element  of  a  certain  class  of  strings  in  a  particular 
construction.  For  this  purpose,  the  name  of  the  descriptor  (in  capitals) 
is  enclosed  in  carats.  As  an  example,  ' <TYPE> '  might  be  introduced  to 
stand  for  any  of  the  strings  'COMBAT',  'COMBAT  SUPPORT',  or  'SERVICE 
SUPPORT'.  The  construction  '<TYPE>  ELEMENT'  would  then  stand  for  any  of 
the  strings  'COMBAT  ELEMENT',  'COMBAT  SUPPORT  ELEMENT',  or  'SERVICE  SUPPORT 
ELEMENT'. 

c.  Alternatives 

When  any  one  of  several  strings  may  be  utilized  in  some 
construction,  the  class  may  be  defined  by  listing  the  alternative  strings 
separated  by  single  bars  ('/').  A  common  use  of  this  notation  is  in 
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defining  descriptors;  for  example,  the  descriptor  <TYPE>  could  be  defined 
as  follows: 

<TYPE>  =  COMBAT  /  COMBAT  SUPPORT  /  SERVICE  SUPPORT 
The  descriptor  and  alternative  notations  will  sometimes  be  combined  as  in: 

< COMBAT  /  COMBAT  SUPPORT  /  SERVICE  SUPP0RT> 

d.  Sequences 

Given  the  frequent  occurrence  of  repetitive  structures  such 
as  lists,  it  is  convenient  to  have  some  means  of  representing  arbitrary 
(non-empty)  sequences  of  strings.  For  this  purpose,  braces  are  utilized 
('{'  and  A  common  usage  of  this  notation  is  exemplified  by 

{< COMBAT  /  COMBAT  SUPPORT  /  SERVICE  SUPPORTS, 
which  represents  any  non-empty  sequence  of  the  strings  'COMBAT',  'COMBAT 
SUPPORT',  and  'SERVICE  SUPPORT'  separated  by  commas.  (The  comma  following 
the  last  string  in  the  sequence  may  be  omitted. 

e.  Optional  Strings 

The  final  general  convention  adopted  provides  a  means  of 
reflecting  the  optional  occurrence  of  a  string  in  a  given  construct.  The 
optional  string  is  simply  enclosed  in  brackets  ('['  and  ']').  Thus,  for 
example, 

'[COMBAT]  SERVICE  SUPPORT' 

represents  either  the  string  'COMBAT  SERVICE  SUPPORT'  or  'SERVICE  SUPPORT'. 

2.  Information  Block  Description  Conventions 

Rather  than  simply  describing  input  value  statements  associated 
with  given  information  blocks,  the  blocks  themselves  will  be  presented  and 
described.  Besides  simplifying  the  language  description,  this  practice 
provides  an  opportunity  to  present  the  overall  block  structure  and  discuss 
the  information  elements  it  contains.  The  format  adopted  for  block  presen¬ 
tation  involves:  (1)  a  graphic  portrayal  of  the  block,  and  (2)  a  descrip¬ 
tion  of  certain  of  its  information  elements  (including  range  and  input 
format). 

a.  Graphic  Portrayal 

The  format  for  graphic  portrayal  of  an  information  block  is 
exemplified  in  Figure  1-4.  Information  conveyed  in  the  graphic  portrayal 
will  now  be  highlighted. 
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1 )  Block  Heading 

The  block  heading  gives  the  informal  name  applied  to 
the  type  of  block  ("Type-A-Block")  and  also  specifies  the  formal  block 
identifier  in  brackets  ("ABLOCK"). 

2)  Information  Element  Groups 

The  particular  information  elements  contained  in  the 
block  are  frequently  presented  in  groups  to  facilitate  description.  In  the 
example,  three  groups  exist:  (1)  Block  Administration  Information,  (2) 
First  Information  Group,  and  (3)  Second  Information  Group.  Most  Cl  infor¬ 
mation  blocks  contain  the  Block  Administration  Information  group.  It  con¬ 
tains  information  elements  used  by  the  software  in  managing  the  creation 
and  release  of  instances  in  the  block;  these  information  elements  are 
uniformly  deleted  in  this  manual  since  they  are  transparent  to  the  user. 
This  is  also  suggested  by  the  hatching  which  indicates  that  direct  (user) 
inputs  are  not  made  to  these  information  elements. 

It  is  emphasized  that  the  information  groups  have  no 
significance  to  the  software  which  processes  the  blocks;  they  are  merely  an 
9  aid  to  presenting  the  blocks. 

3)  Information  Elements 

Three  basic  characteristics  of  the  actual  information 
elements  contained  in  the  block  are  presented  in  the  graphic  portrayal: 
(1)  the  informal  name  of  the  information  element  ("ELEMENT  1");  (2)  the 
formal  identifier  of  the  information  element  ("ELEM1")  used  by  the  soft¬ 
ware;  and  (3)  the  number  of  bits  allocated  for  storage  of  values  assigned 
to  the  information  element  (10  bits  for  ELEM1).  Certain  other  features  of 
the  information  elements  are  suggested  in  the  graphic  portrayal.  If  an 
information  element  (or  group)  is  masked  with  cross-hatching,  it  is  not  a 
direct  user  input  (i.e. ,  it  cannot  be  set  by  an  input  value  statement). 
Also,  if  an  information  element's  formal  identifier  is  starred  (as  is 
ELEMENT  4— "ELEM4*") ,  the  element  implements  a  pointer  to  some  information 
block. 

b.  Description  of  the  Block 

A  verbal  description  of  each  information  block  supplements 
.  its  graphic  portrayal.  This  description  generally  includes  a  description 
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of  the  overall  block,  its  purpose  in  the  model,  and  its  relation  to  other 
blocks.  Certain  information  elements  contained  in  the  block  are  then 
described.  Non-direct-input  (hatched)  information  elements  may  or  may  not 
be  discussed.  Direct  input  information  elements  are  always  described  by 
means  of  an  informal  characterization  of  what  they  represent  and,  in  some 
cases,  how  they  are  used  in  the  model.  In  addition,  the  range  and  input 
format  of  direct  input  information  elements  are  specified. 

1)  Range 

The  range  of  an  information  element  is  specified  in 
terms  of  the  permissible  values  which  may  be  input  to  the  element.  This 
implicitly  specifies  the  precision  and  the  units  of  the  information 
element. 

2)  Input  Format 

The  input  format  may  be  specified  explicitly  in  terms 
of  the  form  of  strings  which  constitute  acceptable  input  values;  this  is 
frequently  used  for  indication  type  information  elements.  Alternatively, 
input  format  may  be  specified  by  reference  to  a  standard  format  such  as 
"real"  or  "integer." 

3.  Input  Statement  Conventions 

2 

The  final  set  of  conventions  to  be  presented  concerns  the  C  l 
UOIL  input  statements  themselves. 

a.  Format 

2 

Each  C  I  UOIL  input  statement--an  input  control  statement  or 
an  input  value  statement— must  appear  on  a  single  line  ("card  image");  any 
other  statement  on  that  line  will  be  regarded  as  a  syntax  error.  However, 
the  statement  may  appear  anywhere  on  the  line;  this  enables  the  user  to 
employ  indentation  to  reflect  "nesting"  of  structure  inputs. 

b.  Input  Control  Statement  Conventions 

Many  of  the  C^I  UOIL  input  control  statements  are  made  up  of 
a  keyword  (signalling  the  start  of  input  for  a  certain  type  of  block  or 
structure)  together  with  a  name  (to  be  "attached"  to  the  resulting  struc¬ 
ture  for  referencing  later  in  the  input  text).  Such  names  may  be  arbi¬ 
trarily  assigned  by  the  user  subject  to  one  constraint:  no  name  may  be 
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used  to  refer  to  more  than  one  structure  1_n  the  overall  i nput  text.  In 
other  words,  once  a  name  such  as  "Blue  Corps"  is  used,  it  may  not  be  used 
again  (except,  of  course,  in  refering  back  to  the  structure  it  was 
initially  associated  with).  Inadvertent  use  of  a  single  name  to  refer  to 
more  than  one  structure  will  cause  a  UOIL  syntax  error, 
c.  Input  Value  Statement  Conventions 

Input  value  statements  in  the  C2I  UOIL  set  particular  infor¬ 
mation  elements  in  a  block  to  particular  values.  They  all  have  the  same 
format  which  is: 

INFORMATION  ELEMENT  IDENTIFER>  =  <VALUE>. 

where: 

(1)  < INFORMATION  ELEMENT  IDENTIFIER>  is  the  "name"  of  the  information 
element  within  the  block  being  input,  and, 

(2)  <VALUE>  is  a  permissible  value  for  the  information  element. 

This,  for  example,  'ELEM1=14'  would  cause  the  information  element  iden¬ 
tified  by  ' ELEM1 '  in  an  ABLOCK  to  be  set  to  a  value  of  14  (see  Figure  1-4, 
above).  Not  all  information  elements  in  a  block  need  be  input.  Thus, 
omitting  an  input  value  statement  for  some  particular  information  element 
in  a  block  will  not  cause  an  error  in  the  UOIL;  it  will  simply  leave  a 
value  of  0  in  that  information  element. 


C.  INITIATING  THE  C2I  INPUT  PROCESSES 

2 

To  initiate  the  Cl  input  processing,  all  inputs  must  be  preceded  by 
the  line, 

C2I. 

2 

This  line  invokes  the  proper  procedures  to  begin  receiving  C  I  inputs 

including  Fundamental  Knowledge,  UOS  Specifications  and  Directives  as  dis- 

2 

cussed  in  Chapters  II,  III,  and  IV,  below.  The  C  l  inputs  cannot  be 
entered  until  all  combat  interactions  inputs  have  been  made  as  described  in 
the  User's  Manual,  Volume  II. 
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CHAPTER  II 

FUNDAMENTAL  KNOWLEDGE  INPUTS 

2 

The  bulk  of  the  EAD  Cl  inputs  specify  Fundamental  Knowledge  compo¬ 
nents  of  UOS  structures.  Fundamental  Knowledge  components  do  not  change 

2 

over  the  course  of  a  simulation  run.  Moreover,  the  Cl  processes  have  been 

2 

designed  to  permit  many  Cl  elements  to  share  Fundamental  Knowledge  compo¬ 
nents,  thus  concerving  storage  space  and  facilitating  input  preparation. 
For  example,  the  user  may  prepare  and  input  one  set  of  concepts  of  opera¬ 
tion  for  each  side  of  the  simulation.  By  naming  each  set  of  concepts 

(e.g. ,  "Blue  concepts"  and  "Red  concepts"),  it  becomes  possible  to  provide 
2 

C  I  element  access  to  the  appropriate  set  via  the  name  rather  than  inputing 
the  same  set  repeatedly. 

2 

Thus,  the  first  step  in  reparing  the  C  I  input  is  to  create  (input) 
named  UOS  components  which  can  be  referenced  during  the  creation  of  UOS's 
for  individual  EAD  Cl  elements.  In  broad  terms,  the  types  of  UOS  compo¬ 
nents  which  are  constructed  in  this  step  include:  (1)  Standard  Operating 
Procedures  (SOP)  Information;  (2)  Updating  Thresholds  and  Flags  (considered 

part  of  SOP  information,  but  constructed  separately  to  facilitate  broader 
2 

sharing  among  Cl  elements);  (3)  Sets  of  Concepts  of  Operation;  (4)  Sets  of 
Weapons  Employment  Concepts;  and  (5)  Sets  of  Weapons  Parameters  (considered 
a  part  of  Employment  Concepts,  but  constructed  separately  to  permit  broader 
sharing  among  C  I  elements).  In  some  cases,  subordinate  information  struc¬ 
tures  are  also  constructed  as  named  UOS  components  within  these  broad 
structures.  The  reader  is  referred  to  the  Software  Description,  Volume  II, 

Chapter  II,  Sections  B-F,  for  further  discussion  of  Fundamental  Knowledge 

2 

components  of  the  UOS.  EAD  C  l  activities  themselves  are  discussed  in  the 
Modeling  Description,  Volume  V,  and  also  in  the  Software  Description, 
Volume  III. 
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A.  CREATE  NAMED  SOP  COMPONENTS 

As  described  in  the  Software  Description,  Volume  II,  Chapter  II, 
Section  B,  an  SOP  component  consists  of  a  fixed  block  of  parameters  des¬ 
cribing  friendly  and  enemy  operational  norms,  timing  information,  nuclear/ 
chemical  weapon  employment  information,  and  message  security  and  priority 
information.  In  addition,  an  SOP  component  includes  references  to  lists  of 
nuclear  and  chemical  readiness  blocks.  These  lists  are  created  first  as 
named  UOS  components  and  then  referenced  by  name  in  creating  the  SOP  para¬ 
meter  blocks. 

SOP  components  would  typically  vary  between  sides.  Moreover,  since 
certain  SOP  information— notably  operational  norms— reflects  character¬ 
istics  of  different  echelons  of  command,  SOP  components  would  also  vary 
among  echelons  within  a  given  side.  Thus,  it  is  expected  that  there  will 
typically  be  at  least  six  distinct  SOP  components  (2  sides  x  3  echelons  per 
side). 

To  initiate  the  creation  of  named  SOP  components,  the  line: 

'SOP' 

must  precede  the  inputs  which  define  the  components. 

1 .  Create  Named  Readiness  Lists 

The  first  step  in  creating  named  SOP  components  is  to  create  an 
appropriate  set  of  named  readiness  lists.  Each  readiness  list  consists  of 
an  ordered  list  of  readiness  blocks  which  define  nuclear  and  chemical 
readiness  states  and  corresponding  actions  to  be  taken  to  adapt  to  those 
readiness  states.  The  ordering  of  the  list  reflects  increasing  readiness 
states. 

Typically,  readiness  doctrines  would  vary  between  sides;  thus, 
there  would  generally  be  at  least  two  nuclear  and  two  chemical  lists. 
Additional  lists  may  be  needed  if  it  is  desired  to  distinguish  readiness 
doctrines  at  different  echelons  of  command. 

To  initiate  the  creation  of  a  specific  readiness  list,  the  line: 

1  READINESS  LIST  =  ||NAME||  <NUCLEAR/CHEMICAL> ' 
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must  precede  the  inputs  of  the  various  readiness  blocks  to  be  included  in 
the  list.  The  inputs  defining  each  readiness  block  must  be  preceded  by  the 
line: 

1 RDYBLK1 


Blocks  must  be  input  in  order  of  increasing  threat  state  value.  Readiness 
block  structure  is  presented  in  Figure  II-l.  Specific  inputs  will  now  be 
discussed. 

a.  Readiness  State 

An  integer  representing  the  readiness  state  defined  by  the 

block. 

•  Range:  0-7  (0  =  "lowest"  readiness  state) 

•  Input  Format:  Integer 

b.  Lower  and  Upper  Threat  Index  Limits 

Thresholds  on  the  appropriate  threat  index  which  define  the 
threat  index  interval  over  which  the  readiness  block  is  valid.  Readiness 
blocks  adjacent  in  the  readiness  list  should  have  contiguous  threat  inter¬ 
vals;  moreover,  the  threat  intervals  of  all  readiness  blocks  in  the  list 
should  cover  the  entire  threat  index  range  (0.00-40.95).  In  other  words, 
the  threat  intervals  should  partition  the  entire  range  of  the  threat  index. 

•  Range:  0.00-40.95 

•  Input  Format:  Real 

c.  High  Threat  Targeting  Concept 

A  flag  which  indicates  whether  or  not  the  "high-threat" 
weapons  employment  concept  is  to  be  used  in  employing  conventional  weapons. 

•  Range:  0,1  (1  =  use  high-threat  concept) 

•  Input  Format:  Integer 

d.  Information  Reguired 

A  flag  which  indicates  whether  or  not  information  should  be 
requested  from  subordinate  force  elements. 

•  Range:  0,1  (1  =  request  information) 

•  Input  Format:  Integer 
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READINESS  BLOCK 

(RDYBLK) 


BASIC  READINESS  BLOCK  INFORMATION 


READINESS  STATE 

RDYST 

3 

LOWER  THREAT  INDEX  LIMIT 

LOTHRT 

12 

UPPER  THREAT  INDEX  LIMIT 

HITHRT 

12 

RESPONSE  ACTIONS 


HIGH  THREAT  TARGETING  CONCEPT 
INFORMATION  REQUIRED 
REPORT  REQUIRED 

WEAPONS  EMPLOYMENT  ACTION  FLAGS 
GROUND  OPERATIONS  DEVELOPMENT  ACTIONS 


STRUCTURE  INFORMATION 


Figure  II-l.  Readiness  Block  Structure 

and  Content 


HITTGT  1 

INFRQD  1 

RPTRQD  1 

WPNACN  6 

GNDACN  1 5 
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e.  Report  Required 

A  flag  which  indicates  whether  or  not  a  report  should  be 

2 

formulated  and  transmitted  to  the  parent  Cl  element. 

•  Range:  0,1  (1  =  send  report) 

•  Input  Format:  Integer 

f.  Weapons  Employment  Action  Flags 

A  sequence  of  flags  representing  the  types  of  weapons,  if 
any,  for  which  weapons  employment  considerations  should  be  initiated. 

•  Range:  N/A 

•  Input  Format:  {<C0NVEN/NUC/CHM>,} 

g.  Ground  Operations  Development  Actions 

A  sequence  of  flags  representing  the  types  of  ground  opera¬ 
tions  development  actions  which  should  be  initiated. 

•  Range:  N/A 

•  Input  Format:  {<ADV-NXT-PHASE 

COMMIT- RESRVS 

A0JUST- RESOURCE | IMPL-ADJUST 

mooify-opn|impl-mod! 

OEVELOP-NEW  |lMPL-NEW>,} 

2.  Create  Named  SOP  Blocks 

Once  an  appropriate  list  of  named  readiness  lists  has  been 
created,  the  named  SOP  blocks  can  be  created.  The  inputs  defining  each 
block  must  be  preceded  by  the  line: 

'SOP  =  | (NAME  I) ' 

SOP  block  structure  is  presented  in  Figure  II-2.  Specific  inputs  will  now 
be  discussed. 

a.  Friendly  Operational  Norm  Information 

These  information  elements  represent  "normal"  or  "typical" 
friendly  values  of  various  factors  and  parameters  involved  in  the  develop¬ 
ment  and  execution  of  operations.  Values  for  these  norms  may  vary  among 
echelons  of  command. 


IMPL-COMMIT| 
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STANDARD  OPERATING  PROCEDURES  DATA  BLOCK 

(SOPBLK) 

FRIENDLY  OPERATIONAL  NORM  INFORMATION 

CAS  RESERVATION  FRACTION 

CASRFR 

7 

SUBORDINATE  CAS  ALLOCATION 

SUBCAS 

12 

INTERDICTION  RESERVATION  FRACTION 

INTRFR 

7 

SUBORDINATE  INTERDICTION  ALLOCATION 

SUBINT 

12 

NUCLEAR  WEAPONS  RESERVATION  FRACTION 

NUCRFR 

7 

NUC  THREAT  PERCEPTION  MODIFICATION  FACTOR 

NUCTMF 

9 

SUBORDINATE  NUCLEAR  WEAPONS  ALLOCATION 

SUBNUC 

18 

CHEMICAL  WEAPONS  RESERVATION  FRACTION 

CHMRFR 

7 

CHEM  THREAT  PERCEPTION  MODIFICATION  FACTOR 

CHMTMF 

9 

SUBORDINATE  CHEMICAL  WEAPONS  ALLOCATION 

SUBCHM 

18 

SUPPLY  DISTRIBUTION  FRACTION 

SUPDST 

7 

SUBORDINATE  SUPPLY  ALLOCATION 

SUBSUP 

18 

REPLACEMENT  DISTRIBUTION  FRACTION 

RPLDST 

7 

OVERALL  FORCE  FULL  STRENGTH 

TOESTR 

18 

SUBORDINATE  COMBAT  FULL  STRENGTH 

TOESUB 

18 

OWN  INEFFECTIVENESS  THRESHOLD 

OWN INF 

9 

SUBORDINATE  ADVANCE  RATE 

SUBADV 

7 

HIGH  FORCE  BALANCE  ADVANCE  RATE  FACTOR 

HIHI 

9 

LOW  FORCE  BALANCE  ADVANCE  RATE  FACTOR 

LOLO 

9 

MAXIMUM  SEPARATION  FOR  RESERVE  COMMITMENT 

MXRSCS 

7 

ENEMY  OPERATIONAL  NORM  INFORMATION 

RELEVANT  OPPOSING  C2l  ECHELON 

RC2IEC 

3 

RELEVANT  OPPOSING  N0N-C2I  ECHELON 

ROTHEC 

3 

RELATIVE  OVERALL  FORCE  SIZE 

OVRRSZ 

9 

RELATIVE  SUBORDINATE  FORCE  SIZE 

SUBRSZ 

9 

ENEMY  INEFFECTIVENESS  THRESHOLD 

ENEINF 

9 

TIMING  INFORMATION 

MAX  TIME  BETWEEN  RESOURCE  ADJUSTMENTS 

MXRATM 

18 

MIN  TIME  BETWEEN  RESOURCE  ADJUSTMENTS 

MNRATM 

18 

MIN  TIME  BETWEEN  OPERATION  MODIFICATION 

MNOMTM 

18 

PLANNING  DELAY  TIME 

PLANTM 

18 

REGULAR  REPORTING  INTERVAL 

RPTINT 

18 

COMPREHENSIVE  REVIEW  INTERVAL 

RVWINT 

18 

MAX  EOB/TGT  BLOCK  AGE 

MXETAG 

18 

MAX  SITUATION  FEATURE  BLOCK  AGE 

MXSFAG 

18 

• 

• 

Figure  II-2.  STD  Operating  Procedures  Data  Block  Information  Structure 
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NUCLEAR/CHEMICAL  EMPLOYMENT  INFORMATION 


NUCLEAR/CHEMICAL  EMPLOYMENT  INFORMATION 


NUCLEAR  EMPLOYMENT  JUSTIFICATION  MASK 
SUBORDINATE  NUCLEAR  EMPLOYMENT  INDICATOR 
MINIMUM  NUCLEAR  EMPLOYMENT 
MAXIMUM  NUCLEAR  EMPLOYMENT 
MIN  TIME  BETWEEN  NUCLEAR  REQUEST 

CHEMICAL  EMPLOYMENT  JUSTIFICATION  MASK 
SUBORDINATE  CHEMICAL  EMPLOYMENT  INDICATOR 
MINIMUM  CHEMICAL  EMPLOYMENT 
MAXIMUM  CHEMICAL  EMPLOYMENT 
MIN  TIME  BETWEEN  CHEMICAL  REQUESTS 

MAX  ENEMY  RESPONSE  STRENGTH  REDUCTION 
MAX  COLLATERAL  DAMAGE  PER  EMPLOYMENT 
MAX  COLLATERAL  DAMAGE  PER  ASSIGNMENT 
WEAPONS  REQUEST  FILL  FRACTION 


MESSAGE  INFORMATION 


DIRECTIVE  SECURITY 
DIRECTIVE  PRIORITY 
REQUEST  SECURITY 
REQUEST  PRIORITY 
REPORT  SECURITY 
REPORT  PRIORITY 


N 
S 
M 

MAXNUC 

MNNRTM 


MAXCHM 

MNCRTM 

MXESTR 

MXCDEM 

MXCDAS 

WRFILL 


DIRSEC 

DIRPRI 

REQSEC 

REQPRI 

RPTSEC 

RPTPRI 


Figure  I 1-2.  STD  Operating  Procedures  Data  Block  Information 
Structure  (Continued) 
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1 )  Reservation  Fractions 

Fractions  reflecting  the  "normal"  portions  of  available 

resources--CAS,  interdiction*  nuclear  and  chemical  weapons--which  would  be 
2 

reserved  by  a  C  I  element  for  its  own  discretionary  control. 

•  Range:  0.00  -  1.00 

•  Input  Format:  Real 

2)  Distribution  Fractions 

Fractions  reflecting  the  "normal"  extent  to  which 

supplies  and  replacements  would  be  made  available  to  subordinates  rather 

2 

than  retained  by  a  Cl  element  for  later  use. 

•  Range:  0.00  -  1.00 

•  Input  Format:  Real 

3)  Subordinate  Allocations 

Absolute  "normal"  allocations  of  resources--CAS,  inter¬ 
diction,  nuclear  and  chemical  weapons,  and  supplies-- to  a  "typical"  sub¬ 
ordinate  in  a  developed  operation.  (Should  be  set  to  0  if  subordinates  are 
not  to  be  allocated  resources.) 


Ranges: 

•• 

CAS  &  Interdiction: 

0-4000  sorties/day 

•• 

Nuclear  Weapons: 

0-262,000  nuclear  weapons  units 
(e.g. ,  kilotons) 

•• 

Chemical  Weapons: 

0-262,000  chemical  weapons  units 
(e.g. ,  tons) 

•• 

Supplies: 

0-262,000  tons/day 

•  Input  Format:  Integer 

4)  Threat  Perception  Modification  Factors 


A  parameter  reflecting  the  extent  to  which  desired 
allocations  of  nuclear  and  chemical  weapons  for  planning  purposes  are 
increased  by  higher  nuclear  or  chemical  threat  indices.  The  higher  the 
threat  modification  factor,  the  greater  will  be  reservations  and  desired 
allocations.  A  value  of  0.00  nullifies  the  threat  perception  modification. 

•  Range:  0.00  -  5.00 

•  Input  Format:  Real 
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5)  Full  Strength  Norms 

The  nominal  full  or  "TOE"  strength  of  the  overall  force 

2 

and  subordinate  force  elements  commanded  by  a  given  C  I  element.  (Varies 
with  side  and  echelon  of  command). 

•  Range:  0  -  262,000  strength  units 

•  Input  Format:  Integer 

6)  Own  Ineffectiveness  Threshold 

A  threshold  on  aggregate  force  capabilities  (extent  of 
suppression)  above  which  subordinate  force  ...elements  should  be  considered 
ineffective. 

•  Range:  0-512  (512  =  "complete"  suppression) 

•  Input  Format:  Integer 

7)  Subordinate  Advance  Rate 

The  expected  rate  at  which  subordinate  force  elements 
will  move  towards  assigned  objectives  in  "normal"  force  balance  conditions. 

•  Range:  0-128  kilometers/hour 

•  Input  Format:  Integer 

8)  High/Low  Force  Balance  Advance  Rate  Factors 
Essentially  scaling  factors  to  be  applied  to  expected 

subordinate  advance  rates  to  adjust  for  favorable  or  unfavorable  force 
balance  conditions. 

•  Range:  0.00  -  5.00 

t  Input  Format:  Real 

9)  Maximum  Separation  For  Reserve  Commitment 

The  maximum  lateral  distance  (within  the  standard  100  x 
200  planning  grid)  by  which  a  reserve  force  element  can  be  separated  from  a 
forward  force  element  and  still  be  considered  for  commitment  in  support  of 
that  force  element. 

•  Range:  0-100  planning  grid  units 

•  Input  Format:  Integer 

b.  Enemy  Operational  Norm  Information 

These  information  elements  represent  "normal"  or  "typical" 
enemy  values  of  various  parameters  and  factors  involved  in  the  development 
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and  execution  of  operations.  As  with  friendly  operational  norms,  values 
may  be  expected  to  vary  among  echelons  of  command. 

1)  Relevant  Opposing  Echelons 

The  enemy  echelon  which  is  of  principal  interest  to  the 
2  2 

given  C  l  element.  The  relevant  C  l  echelon  will  normally  be  one  echelon 

2 

higher  than  relevant  non-C  I  echelon;  it  will  also  normally  be  the  enemy 

2 

echelon  analagous  to  that  of  the  given  C  l  element. 

•  Range:  N/A 

t  Input  Format:  <BRIGADE/REGIMENT/DIVISION/ 

CORPS  ARMY/ARMY  GROUP/ 

FRONT/THEATER> 

2)  Relative  Force  Sizes 

The  nominal  size  of  a  full  "TOE"  strength  enemy  force 
and  subordinate  force  elements,  relative  to  that  of  friend.y  force  elements 
at  the  corresponding  echelons.  That  is,  for  a  "Blue"  SOP,  relative  force 
sizes  would  be  set  to  the  quotient  of  "Red"  strength  over  "Blue"  strength. 

•  Range:  0.00  -  5.00 

•  Input  Format:  Real 

3)  Enemy  Ineffectiveness  Threshold 

A  threshold  on  aggregate  enemy  force  capabilities 
(extent  of  suppression)  above  which  enemy  force  elements  should  be  con¬ 
sidered  ineffective. 

•  Range:  0  -  512  (512  =  "complete"  suppression) 

•  Input  Format:  Integer 

c.  Timing  Information 

These  information  elements  represent  various  planning 

2 

factors  and  thresholds  on  elapsed  time  between  certain  types  of  C  I 
actions. 

1)  Maximum  Time  Between  Resource  Adjustments 

The  maximum  time  which  should  be  allowed  to  elapse 
between  operations  development  actions  which  adjust  allocations  of 
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2 

resources  among  the  C  I  element  and  its  subordinates.  Used  to  insure  that 
resource  allocations  do  not  become  inappropriate  to  the  situation. 

•  Range:  0  -  4000  hours 

§  Input  Format:  Integer 

2)  Minimum  Time  Between  Resource  Adjustments 

The  minimum  time  which  should  be  allowed  to  elapse 

between  self- initiated  adjustments  of  resource  allocations.  Used  to 
prevent  frequent  resource  adjustments  whose  impact  is  never  realized. 

•  Range:  0  -  4000  hours 

•  Input  Format:  Integer 

3)  Minimum  Time  Between  Operation  Modifications 

The  minimum  time  which  should  be  allowed  to  elapse 

between  self- initiated  modifications  to  an  ongoing  operation.  Used  to 
prevent  frequent  operations  modifications  whose  impact  is  never  realized. 

•  Range:  0  -  4000  hours 

•  Input  Format:  Integer 

4)  Planning  Delay  Time 

The  expected  time  between  the  completion  of  an  opera¬ 
tion  development  action  (resource  adjustment,  operation  modification,  new 
operation  development)  and  the  actual  implementation  of  that  action  at  the 
operating  echelons  (divisions  and  brigades). 

•  Range:  0  -  4000  hours 

•  Input  Format:  Integer 

5)  Regular  Reporting/Comprehensive  Review  Intervals 

Normal  time  intervals  between:  (1)  the  preparation  of 
2 

regular  reports  for  superior  C  I  elements,  and  (2)  the  carrying  out  of  a 
comprehensive  review  of  the  situation. 

•  Range:  0  -  4000  hours 

•  Input  Format:  Integer 

6)  UPS  Purge  Age  Threshold  Information 

The  maximum  age  at  which  Enemy  Order  of  Battle/Target 
blocks  and  Situation  Feature  blocks  may  still  be  retained  in  the  U0S. 
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Beyond  this  age,  the  blocks  may  be  deleted  from  the  UOS  (in  the  first  UOS 
purge  activity  after  the  age  has  been  exceeded). 

•  Range:  0  -  4000  hours 

•  Input  Format:  Integer 

d.  Nuclear/Chemical  Readiness  Information 

This  information  is  contained  in  the  named  readiness  lists 
created  earlier.  References  to  the  desired  lists  are  input  to  the  SOP 
block  by  means  of  the  lists'  names  as  in  the  following  lines: 

'NUCLEAR  READINESS  =  ||  NAME ||  1 
and 

'CHEMICAL  READINESS  =  ||  NAME  || ' 

Of  course,  the  respective  names  refer  to  readiness  lists  input  as  described 
in  Section  1 ,  above. 

e.  Nuclear/Chemical  Employment  Information 

These  information  elements  represent  doctrinal  constraints 
on  the  employment  of  nuclear  and  chemical  weapons. 

1)  Justification  Masks 

Nuclear  and  chemical  employment  justification  masks 

delimit  the  situations  under  which  emeployment  of  the  corresponding  weapons 

may  be  authorized.  The  possible  situations  are:  (1)  Critical  Forward 

Operation  Progress,  (2)  Critical  Forward  Operation  Failure,  (3)  Critical 

Kernel  Operation  Progress,  (4)  Critical  Kernel  Operation  Failure,  (5) 

Critical  Strength,  (6)  Critical  Unit  Balance,  (7)  Critical  Nuclear  Threat, 

and  (8)  Critical  Chemical  Threat.  Any  or  all  of  these  may  be  flagged  as 

acceptable  justifications.  The  justification  masks  may  therefore  be  used 

2 

to  constrain  given  C  I  elements'  employment  of  nuclear  and  chemical  weapons 
to  certain  situations. 

•  Range:  N/A 

•  Input  Format:  {<FWD  PROGRESS/FORWARD  FAIL/ 

KERNEL  PROGRESS/KERNEL  FAIL 
STRENGTH/UNIT  BALANCE/ 

NUCLEAR  THREAT/CHEMICAL  THREAT> ,} 

(named  conditions  are  flagged  as  acceptable  justifications) 
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2)  Subordinate  Employment  Indicators 

2 

Flags  which  indicate  whether  or  not  the  given  Cl 
element's  subordinates  can  develop  employments  of  the  given  type  of 
weapons. 

•  Range:  0,1  (1  =  subordinates  can  employ) 

•  Input  Format:  Integer 

3)  Minimum/Maximum  Employment 

Upper  and  lower  limits  on  the  amount  of  nuclear  or 

chemical  weapons  which  may  be  used  in  a  given  employment.  Provides  an 

2 

additional  means  of  constraining  C  I  elements  in  their  employment  of 
nuclear  and  chemical  weapons. 

•  Range:  0  -  262,000  nuclear  weapons  units  (e.g.  ,  kilotons) 

0  -  262,000  chemical  weapons  units  (e.g.,  tons) 

•  Input  Format:  Integer 

4)  Minimum  Time  Between  Nuclear/Chemical  Requests 

The  minimum  time  which  should  be  allowed  to  elapse 
2 

between  requests  to  a  parent  C  I  element  for  nuclear  or  chemical  weapons. 
y  Used  to  prevent  frequent  requests  which  may  not  be  fully  considered. 

•  Range:  0  -  4000  hours 

•  Input  Format:  Integer 

5)  Maximum  Enemy  Response  Strength  Reduction 
The  maximum  amount  by  which  expected  enemy  strength  may 

be  reduced  in  a  given  employment  of  nuclear  or  chemical  weapons.  Provides 
a  means  of  considering  expected  enemy  response  to  a  nuclear  or  chemical 
attack:  strength  reductions  above  this  threshold  might  cause  an  "unaccep¬ 
table"  enemy  response. 

§  Range:  0  -  262,000  (strength  units) 

•  Input  Format:  Integer 

6)  Maximum  Collateral  Damage 
The  maximum  amount  of  expected  collateral  damage  (per 

employment  or  per  specific  weapons  assignment)  which  is  doctrinally 
acceptable. 
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•  Range:  0  -  262,000  (collateral  damage  units) 

•  Input  Format:  Integer 

7)  Weapons  Request  Fill  Fraction 

The  minimum  portion  of  a  weapons  request  which  can  be 

filled  (authorized).  If  available  authorized  weapons  do  not  exceed  this 

fraction,  the  request  cannot  be  filled,  but  must  rather  be  passed  on  to  the 
2 

parent  C  I  element  for  action. 

•  Range:  0.00  -  1.00 

•  Input  Format:  Real 

f.  Message  Information 

These  information  elements  represent  the  communications 
policies  in  terms  of  the  level  of  security  and  priority  with  which 
different  types  of  messages — directives,  requests,  and  reports--are  to  be 
transmitted. 

1)  Securi ty 

An  integer  reflecting  the  level  of  security  with  which 
different  types  of  messages  should  be  transmitted. 

•  Range:  0  -  3  (3  *  highest  level) 

•  Input  Format:  Integer 

2)  Priority 

An  integer  reflecting  the  priority  with  which  different 
types  of  messages  should  be  transmitted. 

•  Range:  0  -  7  (7  =  highest  priority) 

•  Input  Format:  Integer 

B.  CREATE  NAMED  UPDATING  THRESHOLDS/FLAGS  COMPONENTS 


Collectively,  information  elements  included  in  the  updating  thresholds 
and  flags  components  guide  C  I  elements  as  they  monitor  changes  in  then 
UOS.  In  particular,  as  various  situation  data  and  representation  blocks  in 
the  UOS  are  updated  in  response  to  new  information,  certain  information 
elements  in  the  blocks  are  checked  for  "operationally  significant  changes". 
If  such  changes  are  identified,  a  corresponding  set  of  actions  is  invoked 
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to  accomplish  derivative  UOS  updating  procedures  (aggregating  own  status  or 
enemy  order  of  battle/target  information,  updating  force  balance,  or 
revising  threat  indice)  or  to  check  for  certain  types  of  contingencies  (see 
the  Modeling  Description,  Volume  V,  Chapter  III).  Updating  thresholds  and 
flags  govern  these  processes  by:  (1)  defining  what  constitutes  an  "opera¬ 
tionally  significant  change"  in  the  various  information  elements  (via 
updating  thresholds)  and,  (2)  prescribing  actions  to  be  accomplished  upon 
identification  of  such  changes  (via  updating  flags). 

Updating  thresholds  and  flags  are  properly  considered  to  be  SOP  type 
information.  They  are  organized  separately  because  it  may  be  reasonable  to 
ignore  echelon  differences  and  thus  provide  only  two  sets  of  updating 
thresholds  and  flags  (namely,  one  for  each  side).  The  present  organization 
permits  this. 

As  was  discussed  in  the  Software  Description,  Volume  II,  Chapter  II, 
Section  B,  updating  thresholds  and  flags  are  organized  in  blocks  corres¬ 
ponding  to  the  situation  data  or  situation  representation  blocks  they  are 
used  to  update  and  monitor.  To  facilitate  accessing,  references  to  all 
updating  thresholds/flags  blocks  are  consolidated  in  one  structure  known  as 
the  Updating  Threshold/Flag  (UTF)  Directory.  In  particular,  this  directory 
contains  references  to  Updating  Threshold/Flag  (UTF)  blocks  for:  (1)  basic 
Own  Status  updating,  (2)  aggregiate  Own  Status  updating;  (3)  basic  Enemy 
Order  of  Battle/Target  updating;  (4)  aggregate  Enemy  Order  of  Battle/Target 
updating;  (5)  Situation  Feature  updating;  (6)  Situation  Representation 
updating;  (7)  Nuclear  Threat  Index  updating;  and  (8)  Chemical  Threat  Index 
updating. 

Although  eight  updating  thresSol d/flag  blocks  are  referenced,  only 
four  distinct  types  of  updating  threshold/flag  blocks  exist.  The  first 
four  directory  references  are  to  instances  of  the  unit  block  UTF  block. 
The  fifth  directory  reference  is  to  an  instance  of  the  situation  feature 
UTF  block.  The  sixth  directory  reference  is  to  an  instance  of  the  situa¬ 
tion  representation  UTF  block.  The  seventh  and  eighth  directory  references 
are  to  instances  of  the  threat  updating  parameters  block. 
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The  input  procedure  for  updating  thresholds  and  flags  information 
involves  two  steps.  First,  appropriate  UTF  blocks  are  created  as  named  UOS 
components.  Second,  appropriate  sets  of  these  blocks  are  compiled  into 
named  UTF  directories  for  subsequent  use  in  the  creation  of  individual  UOS 
structures. 

To  initiate  this  procedure,  all  block  and  directory  inputs  must  be 
preceded  by  the  line: 

'UTF' 

This  will  then  be  followed  by  a  sequence  of  individual  named  UTF  block 
inputs  and  then  by  lines  which  create  appropriate  named  UTF  directories. 

1 .  Create  Named  Unit  Block  UTF  Block 

Unit  block  UTF  blocks  are  used  in  monitoring  Own  Status  and  Enemy 
Order  of  Battle/Target  information  at  both  the  basic  level  (i.e. ,  in 
response  to  received  reports)  and  the  aggregate  level  (i.e.,  in  response  to 
a  derivative  aggregation  procedure).  One  block  must  be  created  for  each 
pairing  of  information  type  and  level. 

The  input  for  each  unit  block  UTF  block  must  be  preceded  by  the 

line: 

1  BLOCK  =  |i  NAME  ||  UNITBLK1 

The  strucutre  of  the  unit  block  UTF  block  is  presented  in  Figure  II-3.  Its 
information  elements  will  now  be  discussed  in  terms  of  the  two  basic 
groups:  thresholds  and  flags. 

a.  Unit  Block  UTF  Block  Thresholds 

Threshold  information  elements  in  the  unit  block  UTF  block 
represent  "operationally  significant"  levels  of  change  in  associated  unit 
block  information  elements.  The  significance  of  changes  beyond  the  speci- 
fied  levels  is  that  certain  associated  Cl  actions  are  implemented.  These 
actions  are  represented  by  flags  set  in  the  corresponding  flag  set.  Thus, 
for  example,  if  the  threshold  defining  an  operationally  significant 
strength  increase  is  breached,  the  actions  specified  in  the  strength 
increase  flags  will  be  invoked.  The  possible  actions  will  be  discussed  in 
more  detail  in  the  next  section. 
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UNIT  BLOCK  UPDATING  THRESHOLDS 
AND  FLAGS  (UBUPTF) 


THRESHOLDS 


TARGET  FRACTION  ACQUIRED 

LOCATION  CHANGE 

AXIS  OF  OPERATIONS 

CHANGE 

SECTOR  WIDTH  INCREASE 

II 

_  DECREASE 

ACCELERATION 

DECELERATION 

STRENGTH  INCREASE 

ii 

_  DECREASE 

RESOURCES  INCREASE 

II 

DECREASE 

NUCLEAR  WEAPONS  INCREASE 

II 

DECREASE 

CAPABILITIES  INCREASE 

II 

DECREASE 
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Figure  1 1-4  characterizes  the  unit  block  UTR  block  thres¬ 
holds  in  terms  of:  (1)  the  test  made  and  triggering  condition  under  which 
the  corresponding  actions  will  be  invoked;  (2)  the  range  of  the  threshold; 
and,  (4)  the  input  format  for  the  threshold.  Each  time  an  own  status  or 
enemy  order  of  battle/target  block  is  updated,  all  tests  are  made:  the 
test  variable  is  computed  based  on  the  respective  values  in  the  "new"  block 
and  "old"  block  being  updated.  Actions  associated  with  triggered  test 
conditions  are  accumulated  for  all  tests  and  invoked  upon  completion  of  the 
updating.  (This  precludes  the  wasteful  possibility  of  repeating  a  given 
action  invoked  for  each  of  several  triggered  test  conditions), 
b.  Unit  Block  UTF  Block  Action  Flag  Words 


Associated  with  each  of  the  unit  block  UTF  block  thresholds 

is  a  sequence  of  flags  corresponding  to  various  C  I  actions  which  are  to  be 

carried  out  in  the  event  the  test  condition  defined  by  the  threshold  is 

triggered.  In  fact,  sequences  of  flags  are  also  included  for  certain 

operationally  significant  changes  not  requiring  a  threshold  for  their 

definition.  Such  changes  concern  outright  differences  between  "old"  and 

"new"  values  of  certain  qualitative  information  elements.  These  include: 

nuclear  and  chemical  readiness,  role,  mission,  operation,  at  objective 

indicator,  nuclear  or  chemical  attack  victim  indicator.  The  identification 

2 

of  a  new  enemy  unit  may  also  trigger  the  invocation  of  C  I  actions. 

2 

The  range  of  possible  C  I  actions  which  may  be  flagged  for 

invocation  are  presented  in  Figure  I 1-5.  Note  that  these  include:  (1) 

certain  derivative  UOS  updating  actions  (to  trace  the  effects  of  a  change 

to  other  information  elements  in  the  UOS);  (2)  reporting  actions  (to 

2 

transmit  new  information  to  the  parent  C  I  element);  and,  (3)  contingency 
checking  actions  (to  consider  the  need  for  some  response  to  the  change). 

Each  word  of  flags  in  the  unit  block  UTF  block  represents  a 
string  of  36  action  flags.  Actions  presented  in  Figure  1 1-5  are  repre¬ 
sented  by  the  flags  in  the  bit  positions  indicated  (where  least  significant 
bit  position  =  1).  Thus,  to  invoke  the  updating  of  force  balance  informa¬ 
tion,  the  transmission  of  a  status  report,  and  the  checking  for  an  opera¬ 
tional  progress  contingency  in  response  to  an  operationally  significant 
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Figure  1 1 -4 .  Characterization  of  Unit  Block  UTF  Block  Thresholds 
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ACTION 


BIT  POSITION 


DERIVATIVE  UOS  UPDATING  ACTION 


AGGREGATE  OWN  STATUS  INFORMATION 
AGGREGATE  ENEMY  ORDER  OF  BATTLE/ 
TARGET  INFORMATION 
UPDATE  FORCE  BALANCE  INFORMATION 

REPORTING  ACTIONS 


SEND  STATUS  REPORT 

SEND  UNIT  INTELLIGENCE  REPORT 

SEND  SITUATION  FEATURE  REPORT 


CONTINGENCY  CHECKING  ACTION 


CHECK  NUCLEAR  THREAT  CONTINGENCY 
CHECK  CHEMICAL  THREAT  CONTINGENCY 
CHECK  OPERATIONAL  PROGRESS  CONTINGENCY 
CHECK  TARGET  ENGAGEMENT  OPPORTUNITY 
CONTINGENCY 


2 

Figure  1 1-5 .  Possible  C  I  Actions  Which  Can  Be  Invoked 
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increase  in  strength,  bit  7,  16,  and  35  must  be  set  to  '  1 1  in  the  strength 
increase  flags  word  (STRING). 

•  Range:  21(^  different  combinations  of  actions  may  be 

flagged  in  each  flags  word 

•  Input  Format:  {<bit  position  index>,}  (which  turns 

on  the  bits  in  the  specified  bit  positions) 

2.  Create  Named  Situation  Feature  UTF  Block 

Situation  feature  UTF  blocks  are  used  in  monitoring  Situation 
Feature  information  during  updating  in  response  to  new  situation  feature 
reports. 

The  inputs  for  the  situation  feature  UTF  block  must  be  preceded 
by  the  line: 

'BLOCK  =  || NAME ||  SITFEAT' 

The  structure  of  the  situation  feature  UTF  block  is  presented  in  Figure 
I 1-6 .  Its  information  elements  consist  of  two  action  flag  words  corres¬ 
ponding  to  the  situation  features  nuclear  attack  and  chemical  attack.  Upon 

.  .  2 
recognizing  a  new  nuclear  or  chemical  attack,  the  C  I  actions  flagged  in 

the  coresponding  word  will  be  invoked. 

The  range  of  possible  actions  which  can  be  invoked  is  as  depicted 
in  Figure  I 1-5 ,  above.  Checking  for  nuclear  or  chemical  threat  contingen¬ 
cies  (bit  positions  23  or  24)  would  be  natural  actions. 

•  Range:  2^  different  combinations  of  actions  may  be  flagged 

•  Input  Format:  (<bit  position  index>,}  (which  turns  on  the 

bits  in  the  specified  bit  positions) 

3.  Create  Named  Sitration  Representation  UTF  Block 

Situation  representation  UTF  blocks  are  used  in  monitoring  Situa¬ 
tion  Representation  information  as  it  is  updated  or  revised  in  response  to 
new  situation  data. 

The  inputs  for  the  situation  representation  UTF  block  must  be 
preceded  by  the  line: 

"BLOCK  =  ||  NAME ||  SITREP' 

The  structure  of  the  situation  representation  UTF  block  is  presented  in 
Figure  II-7.  Its  information  elements  will  now  be  discussed  in  terms  of 
the  two  basic  groups:  thresholds  and  flags. 
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SITUATION  REPRESENTATION  UPDATING 
THRESHOLDS  AND  FLAGS  (SRUPTF) 


THRESHOLDS 

" . =  = 

GROSS  UNIT  BALANCE  INCREASE 

GUBINT 

18 

"  DECREASE 

GUBDCT 

18 

DETAILED  UNIT  BALANCE  INCREASE 

DUB I NT 

18 

"  DECREASE 

18 

STRENGTH  BALANCE  INCREASE 

SBLINT 

18 

"  DECREASE 

SBLDCT 

18 

NUCLEAR  THREAT  INDEX  INCREASE 

NTIINT 

18 

"  DECREASE 

NTIDCT 

18 

CHEMICAL  THREAT  INDEX  INCREASE 

CTIINT 

18 

"  DECREASE 

CTIDCT 

18 

FLAGS 

1 

GROSS  UNIT  BALANCE  INCREASE 

36 

"  DECREASE 

36 

DETAILED  UNIT  BALANCE  INCREASE 

36 

"  DECREASE 

DUBDCF 

36 

STRENGTH  BALANCE  INCREASE 

SBLINF 

36 

"  DECREASE 

SBLDCF 

36 

NUCLEAR  THREAT  INDEX  INCREASE 

NTIINF 

36 

"  DECREASE 

NTIDCF 

36 

CHEMICAL  THREAT  INDEX  INCREASE 

CTIINF 

36 

"  DECREASE 

CTIDCF 

36 

Figure  1 1 -7 .  Situation  Representation  UTF  Block 

Structure 


11-24 


fM'H 


THE  BDM  CORPORATION 


a.  Situation  Representation  UTF  Block  Thresholds 

Threshold  information  elements  in  the  situation  represen¬ 
tation  UTF  block  represent  "operationally  significant"  levels  of  change  in 

force  balance  or  threat  information  elements.  The  significance  of  changes 

2 

beyond  the  specified  levels  is  that  certain  associated  C  I  actions  are 
implemented  as  specified  in  flags  words  corresponding  to  the  thresholds. 

Figure  1 1-8  characterizes  the  situation  representation  UTF 
block  thresholds  in  terms  of:  (1)  the  test  made  and  triggering  condition 
under  which  the  corresponding  actions  will  be  invoked;  (2)  the  range  of  the 
threshold;  (3)  a  typical  value  for  the  threshold;  (4)  the  input  format  for 
the  threshold.  Each  time  Situation  Representation  information  is  updated 
or  revised,  all  tests  are  made;  actions  associated  with  triggered  test 
conditions  are  accumulated  and  invoked  upon  completion  of  the  updating  or 
revising. 

b.  Situation  Representation  UTF  Block  Flag  Words 

Associated  with  each  of  the  situation  representation  UTF 

o 

block  thresholds  is  a  word  of  flags  corresponding  to  the  various  C  I 
actions  which  are  to  be  carried  out  in  the  event  the  test  condition  defined 
by  the  threshold  is  triggered. 

The  range  of  possible  actions  which  can  be  invoked  is  as 
presented  in  Figure  I 1-5,  above. 

•  Range:  2^  different  combinations  of  actions  may  be  flagged 

•  Input  Format:  {<bit  position  index>,}  (which  turns  on  the 

bit  in  the  specified  bit  positions) 

4.  Create  Named  Threat  Updating  Parameters  Block 

2 

Threat  updating  parameters  blocks  are  used  by  Cl  elements  as 
they  revise  their  nuclear  and  chemical  threat  indices.  Two  types  of  para¬ 
meters  are  involved:  (1)  a  threat  reduction  parameter  reflecting  the 
extent  to  which  the  threat  index  declines  over  time  in  the  absence  of 
threat  indicators;  and  (2)  threat  scaling  factors  reflecting  the  extent  to 
which  the  threat  index  should  be  altered  for  each  possible  revision  reason 
("indicator").  Separate  blocks  of  such  parameters  are  required  for  nuclear 
threat  updating  and  chemical  threat  updating. 


i§ 
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Figure  I 1-8.  Characterization  of  Situation  Representation  UTF  Block  Threshold 


THE  BOM  CORPORATION 


# 


The  inputs  for  each  threat  updating  parameters  must  be  preceded 
by  the  line: 

'BLOCK  =  |J  NAME  ||  THREAT' 

The  structure  of  the  threat  updating  parameters  block  is  presented  in 
Figure  II-9.  Its  information  elements  will  now  be  discussed, 
a.  Threat  Reduction  Factor 

Reflect  the  extent  to  which  the  corresponding  threat  index 
declares  over  time  in  the  absence  of  specific  revision  reasons.  In  par¬ 
ticular,  the  threat  reduction  factors  are  used  to  scale  down  the  threat 
index  by: 


which  reflects  the  postulate  that  the  threat  index  decreases  though  at  * 
decreasing  rate  over  time. 

•  Range:  0.00  -  40.95 

•  Input  Format:  Real 

b.  Threat  Scaling  Factor  for  Revision  Reason  i 

Prescribes  the  extent  to  which  the  threat  index  should  be 
multiplicatively  scaled  up  or  down  in  response  to  the  ith  revision  reason. 
At  present,  such  a  scaling  factor  must  be  provided  for  15  distinct  revision 
reasons.  If  a  revision  reason  in  interpreted  as  a  particular  type  of 
threat  indicator  and  the  threat  index  is  interpreted  as  the  odds  of  threat 
materialization,  then  the  threat  scaling  factors  can  be  interpreted  as  the 
likelihood  ratios  associated  with  the  revision  reasons. 

•  Range:  0.01  -  40.00  (must  be  strictly  positive) 

•  Input  format:  Real 

5.  Create  Named  UTF  Directories 

Once  appropriate  named  UTF  blocks  of  the  various  types  have  been 
created,  they  can  be  consolidated  into  named  UTF  directories.  To  create  a 
specific  named  UTF  directory,  all  UTF  block  references  must  be  preceded  oy 
the  line: 

'DIRECTORY  =  ||  NAME ||  1 
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References  to  specific  named  UTF  blocks  can  then  be  inserted  into  this 
named  directory  by  lines  of  the  form 

'SET  <ENTRY  TYPE>  =  ||NAME||  1 

where: 


< ENTRY  TYPE>  =  BASIC  OS/AGGREGATE  OS/ 

BASIC  EOB/AGGREGATE  EOB/ 

SIT  FEATURE/SITREP/ 

NUCLEAR  THREAT/CHEMICAL  THREAT 


and, 


||  NAME 1 1  refers  to  the  previously  created  named 

UTF  block  to  be  referenced  by  the  direc¬ 
tory  entry  of  the  specified  type. 


Figure  11-10  illustrates  the  structure  of  a  UTF  Directory. 


C.  CREATE  NAMED  CONCEPT  OF  OPERATION  COMPONENTS 


2 

Concepts  of  operation  guide  C  I  elements  as  they  attempt  to  develop 

2 

operations  to  achieve  objectives  assigned  by  superior  Cl  elements.  A 

2 

concept  of  operation  provides  generalized  guidance  to  a  C  I  element  con- 

,  2 
cermng  one  approach  to  carrying  out  the  assigned  mission.  A  C  l  element 

uses  this  generalized  guidance  by  "fitting"  or  "specializing"  the  concept 

of  operation  to  the  specific  features  of  the  situation  it  faces:  friendly 

and  enemy  forces  information,  assigned  objectives,  and  so  forth.  Of 

course,  a  given  concept  of  operation  may  or  may  not  be  appropriate  in  a 

2 

particular  situation.  Thus,  each  C  I  element  must  be  provided  with  several 
concepts  of  operation  which  it  may  consider,  in  turn,  for  applicability. 
(See  the  Modeling  Description,  Volume  V,  Chapter  IV,  for  further  dis¬ 
cussion;  see  also  the  Software  Description,  Volume  III,  Chpater  IV.) 

As  was  discussed  in  the  Software  Description,  Volume  II,  Chapter  II, 

2 

Section  D,  the  concepts  of  operation  provided  to  each  C  I  element  are 
organized  into  ordered  sets.  A  particular  set  represents  concepts 
generally  applicable  in  a  given  broadly  defined  situation;  at  present,  two 
sets  of  concepts  are  provided:  one  for  offensive  missions  and  one  for 
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defensive  missions.  Within  each  set,  concepts  are  ordered  in  terms  of 
general  ("doctrinal")  preference  (in  the  sense  that  an  envelopment  is 
generally  preferred  to  a  penetration,  which  is,  in  turn,  generally  pre¬ 
ferred  to  a  frontal  attack).  These  preferences  guide  the  order  in  which 

2 

concepts  of  operation  are  considered  by  C  I  elements.  Within  the  model, 
this  organization  is  implemented  in  the  form  of  a  "directory"  of  lists  of 
concepts  of  operation  as  shown  in  Figure  11-11.  Each  entry  in  the  direc¬ 
tory  is  a  reference  to  a  particular  list  of  concepts  of  operation.  Each 
list  corresponds  to  one  of  the  ordered  sets  of  concepts.  (Thus,  at 
present,  only  the  first  two  directory  entries  are  used  --  the  others  are 
provided  for  future  growth.)  Within  each  list,  the  doctrinal  preference 
ordering  is  implemented  by  the  accessing  sequence  of  the  list:  the  first 

concept  on  the  list  is  the  most  preferred,  the  second  concept  is  the  next 

2 

most  preferred  and  so  on.  Each  INWARS  C  I  element  (at  echelons  above 
division)  must  be  provided  access  to  an  appropriate  concept  of  operation 
directory. 

Concepts  of  operation  have  been  designed  to  be  independent  of  echelon 
2 

within  INWARS  Cl  elements:  all  echelons  above  division  can  utilize  the 

same  concept  of,  e.g. ,  an  envelopment.  Thus,  different  concept  directories 

2 

need  not  be  provided  to  Cl  elements  at  different  echelons  of  command. 
Concepts  of  operation  would  typically  vary  between  different  sides,  so  two 
concept  directories  would  generally  be  required. 

Concept  of  operation  directories  are  created  in  two  basic  steps.  In 
the  first  step,  the  directories  themselves  are  created  and  provided  with 
references  to  lists  of  named  concepts.  In  the  second  step,  the  named 
concepts  included  in  the  lists  of  the  named  directories  are  created.  It  is 
emphasized  that  although  a  particular  named  concept  need  be  created  only 
once  (in  the  second  step),  it  may  be  referenced  by  name  in  arbitrarily  many 
of  the  directory  lists.  Thus,  some  concepts  may  appear  in  more  than  one 
list  and/or  directory  --  for  example,  Blue  and  Red  could  share  a  single 
concept  of  "frontal  attack",  if  desired. 

Creation  of  concept  of  operation  directories  is  initiated  by  the  line: 
'CONCEPT  OF  OPERATION' 


11-31 


THE  BOM  CORPORATION 


y.  v 


I  % 


h 


' 


Named  directory  specifications  are  then  input.  Finally,  named  concepts  are 
created. 

1 .  Create  Named  Concept  Directories 

To  create  a  named  concept  directory,  the  specifications  of 
included  concept  lists  must  be  preceded  by  the  line: 

'DIRECTORY  =  ||  NAME 1 1  1 

which  establishes  the  directory  name.  Concept  lists  are  then  created.  The 
creation  of  the  i^  concept  list  is  initiated  by  the  line: 

'CONCEPT  LIST  i' 


This  line  causes  all  following  named  concepts  to  be  linked  into  the  list 

sth 


referenced  by  the  i  concepts  list  pointer  in  the  named  concept  directory 
(see  Figure  11-11 ,  above).  The  concepts  to  be  included  in  this  particular 
list  are  then  specified  in  order  of  doctrinal  preference  ("best"  is  speci¬ 
fied  first)  by  lines  of  the  form: 

'CONCEPT  =  ||  NAME||  ’ 

2.  Create  Named  Concepts 


Creating  named  concepts  of  operation  is  perhaps  the  most 
2, 


elaborate  of  the  Cl  input  procedures  due  to  the  complexity  of  the  concept 
information  structure.  The  creation  of  a  specific  named  concept  is 
initiated  by  the  line; 

'CONCEPT  =  ||  NAMeII  ' 

This  line  establishes  the  named  concept  as  the  context  for  subsequent 
inputs  and  creates  a  concept  header  having  the  structure  portrayed  in 

Figure  11-12.  Inputs  for  each  concept  must  be  terminated  by  an  "END 
CONCEPT'  line  before  another  concept  can  be  created, 
a.  Concept  Header  Block 

As  can  be  seen  in  the  figure,  the  concept  header  block 

contains  many  information  elements,  only  one  of  which  is  a  direct  input. 
For  the  most  part,  the  header  provides  a  repository  for  certain  information 
concerning  the  concept  as  a  whole. 

Most  important  among  those  are  the  various  necessary 

references  (pointers)  to  other  components  of  the  concept:  suitability 

conditions,  operations  parameters,  the  operation  structure,  and  resource 


11-33 


THE  BOM  CORPORATION 


CONCEPT  HEADER  BLOCK 
(CONHDR) 


BASIC  CONCEPT  INFORMATION 


CONCEPT  DESIGNATOR 


CONCPT 


SUITABILITY  CONDITIONS 


OPERATION  APPRAISAL  INFORMATION 


ROLE  STRUCTURE  ADMISSIBILITY 
DEPLOYMENT  ACCEPTABILITY 
KERNEL  VIABILITY 
.  RESOURCE  REASIBILITY 
OVERALL  DESIRABILITY 


OPERATION  TIMING  INFORMATION 


OPERATION  START  TIME 
TIME  OF  LAST  OPERATION  MODIFICATION 
TIME  OF  LAST  RESOURCE  ADJUSTMENT 
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OPERATION  PARAMETERS  INFORMATION 


OPERATION  STRUCTURE  INFORMATION 


RESOURCE  MANAGEMENT  INFORMATION 
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management  blocks.  References  to  these  components  are  inserted  into  the 
concept  header  as  they  are  created  in  subsequent  inputs.  As  this  suggests, 
the  concept  header  may  be  regarded  as  the  "root"  of  the  information 
structure. 

Other  information  elements  in  the  header  are  developed 
during  operations  development  processing  in  the  model.  Operation  appraisal 
and  timing  information  exemplify  this  type  of  information  element. 

1 )  Concept  Designator 

The  sole  direct  input  to  the  concept  header  is  the 
concept  designator  which  is  simply  an  integer  which  identifies  the  concept. 
It  is  not  presently  used  by  the  model: 

•  Range:  0-63 

•  Input  Format:  Integer 
b.  Suitability  Conditions 

The  suitability  conditions  associated  with  a  concept  of 
operation  characterize  the  conditions  under  which  it  is  suitable  for  appli¬ 
cation.  As  discussed  below,  various  types  of  suitability  conditions  may 
presently  be  specified;  each  is  specified  by  a  suitability  condition  block 
defining  the  type  condition,  its  applicability,  and  appropriate  thresholds. 
Collectively,  the  suitability  condition  blocks  are  organized  as  a  list 
attached  to  the  concept  header.  Any  number  of  suitability  conditions  may 
therefore  be  associated  with  a  concept  of  operation. 

To  initiate  the  creation  of  the  list  of  suitability  condi¬ 
tions,  the  line: 

'CONDITION' 

must  precede  the  inputs  for  each  suitability  condition  block.  These  blocks 
have  the  structure  portrayed  in  Figure  11-13.  Their  inputs  will  now  be 
discussed. 

1 )  Condition  Information 

These  two  information  elements  concern  the  type  and 
applicability  of  the  suitability  condition  block. 
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SUITABILITY  CONDITION  BLOCK 
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a)  Suitability  Condition  Type 

An  integer  code  which  specifies  the  type  of 
suitability  condition  in  the  sense  of  what  test  to  make  on  the  situation 
and  how  to  utilize  the  parameters  in  the  block  in  making  the  test.  At 
present,  six  types  of  suitability  conditions  can  be  specified:  (1)  gross 
strength,  (2)  subordinate  strength,  (3)  overall  unit  balance,  (4)  subord¬ 
inate  unit  balance,  (5)  nuclear  threat,  and  (6)  chemical  threat. 

•  Range:  0-63  (1-6  presently  used) 

•  Input  Format:  GROSS  STR/SUB-STR/ 

GROSS  BAL/SUB-BAL/ 

NUC-THRT/CHM-THRT 

b)  Relative  Position  Criterion 

A  set  of  three  flags  which  limit  the  applicability 
of  suitability  conditions  dealing  with  subordinate  status  to  subordinates 
in  designated  relative  positions  ("left",  "interior",  or  "right"),  can  be 
used,  e.g. ,  to  impose  a  force  balance  condition  which  applies  only  to  the 
left-most  subordinate. 

3 

t  Range:  2  distinct  combinations  possible 

•  Input  Format:  {<LEFT/INTERIOR/RIGHT> , } 

2)  Condition  Thresholds 

The  suitability  condition  block  provides  space  for  a 
pair  of  thresholds  defining  an  interval  on  some  situation  information 
element  over  which  the  concept  is  considered  "suitable".  Since  different 
types  of  suitability  conditions  concern  different  types  of  situations,  the 
thresholds  must  be  interpreted  correspondingly. 

a)  Strength  Thresholds 

Upper  and  lower  thresholds  defining  the  interval 
of  relative  or  fractional  strength  (with  respect  to  normal  "full"  or  "TOE" 
strength)  over  which  the  concept  is  suitability: 

•  "Range:  0-100 

•  Input  Format:  Real 
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b)  Force  Balance  Thresholds 

Upper  and  lower  thresholds  defining  an  interval  of 
detailed  unit  balance  over  which  the  concept  is  "suitable". 

•  Range:  0.00  -  40.00 

•  Input  Format:  Real 

c)  Nuclear/Chemical  Threat  Index  Thresholds 

Upper  and  lower  thresholds  defining  an  interval  of 
nuclear  or  chemical  threat  over  which  the  concept  is  "suitable". 

•  Range:  0.00  -  40.00 

t  Input  Format:  Real 

c.  Operation  Parameters 

A  concept  is  further  characterized  by  various  parameters 
involved  in  the  development  and  execution  of  operations  under  that  concept. 
These  parameters  are  organized  into  a  fixed  block  having  the  structure 
portrayed  in  Figure  11-14.  The  line: 

'OPERATION  PARAMETERS' 

initiates  the  procedure  to  receive  the  operation  parameter  inputs  which 
will  now  be  discussed. 

1 )  Operation  Appraisal  Weighting  Factors 

These  information  elements  represent  the  relative 
importance  of  various  appraisal  results  to  the  overall  appraisal  of  the 
concept.  They  are  expressed  as  weights  used  to  aggregate  the  corresponding 
appraisal  results  into  broader  appraisals. 

a)  Resource  Weighting  Factors 

Weight  reflecting  the  relative  importance  of 
individual  types  of  resources  --  CAS,  interdiction,  nuclear  and  chemical 
weapons,  supplies,  and  replacements  --  to  the  concept.  Used  to  aggregate 
feasibility  appraisals  of  individual  resource  types  into  an  overall 
appraisal  of  resource  feasibility. 

•  Range:  0.00  -  5.00 

•  Input  Format:  Real 
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OPERATION  PARAMETERS  BLOCK 


(PARBLK) 


OPERATION  APPRAISAL  WEIGHTING  FACTORS 


CAS  WEIGHTING 

INTERDICTION  WEIGHTING 

NUCLEAR  WEAPONS  WEIGHTING 

CHEMICAL  WEAPONS  WEIGHTING 

SUPPLY  WEIGHTING 

REPLACEMENT  WEIGHTING 

ROLE  STRUCTURE  ADMISSIBILITY  WEIGHTING 

DEPLOYMENT  ACCEPTABILITY  WEIGHTING 

KERNEL  VIABILITY  WEIGHTING 

RESOURCE  FEASIBILITY  WEIGHTING 


OPERATION  APPRAISAL  MINIMUM  LEVELS 


MINIMUM  ROLE  STRUCTURE  ADMISSIBILITY 
MINIMUM  DEPLOYMENT  ACCEPTABILITY 
MINIMUM  KERNEL  VIABILITY 
MINIMUM  RESOURCE  FEASIBILITY 
MINIMUM  OVERALL  DESIRABILITY 


OPERATION  PROGRESS  APPRAISAL  INFORMATION 


UPPER  FORWARD  OPERATION  PROGRESS  THRESHOLD 
LOWER  FORWARD  OPERATION  PROGRESS  THRESHOLD 
UPPER  KERNEL  OPERATION  PROGRESS  THRESHOLD 
LOWER  KERNEL  OPERATION  PROGRESS  THRESHOLD 
ADVANCE  TO  NEXT  PHASE  THRESHOLD 


CHMWT 

SUPWT 

RPLWT 

ADMIWT 

ACCPWT 

VIABWT 

FEASWT 


MNDESR 
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OPERATIONS  PARAMETERS  BLOCK  (PARBLK) 

FWD  GOOD,  KER  GOOD  OPNS  DEVEL  ACTIONS 

FGKGOD 

15 

FWD  GOOD,  KER  GOOD  WPNS  EMPLOY  ACTIONS 

GDKGWE 

6 

FWD  GOOD  KER  OK 

FWD  GOOD,  KER  OK 

FED  GOOD,  KER  POOR 

FWD  GOOD,  KER  POOR 

FWD  OK,  KER  GOOD 

FWD  OK,  KER  GOOD 

FWD  OK,  KER  OK 

• 

mm 

FWD  OD,  KER  OK 

• 

• 

mm 

FWD  OK,  KER  POOR 

FWD  OK,  KER  POOR 

FWD  POOR,  KER  GOOD 

FWD  POOR,  KER  GOOD 

FWD  POOR,  KER  OK 

FWD  POOR,  KER  OK 

FWD  POOR,  KER  POOR 

FPKPOD 

15 

FWD  POOR,  KER  POOR 

FPKPWE 

6 

|  CRITICAL  SITUATION  DIAGNOSIS  INFORMATION 

CRITICAL  FORWARWARD  OPERATION  PROGRESS  THRESH. 

CRFWDP 

4 

CRITICAL  FORWARD  OPERATION  FAILURE  LEVEL 

CRFWFL 

7 

CRITICAL  KERNEL  OPERATION  PROGRESS  THRESH. 

CRKERP 

4 

CRITICAL  KERNEL  OPERATION  FAILURE  LEVEL 

CRDELF 

7 

.  CRITICAL  FRACTIONAL  STRENGTH 

CRFRST 

7 

CRITICAL  UNIT  BALANCE 

CRUBAL 

12 

CRITICAL  NUCLEAR  THREAT 

CRNUCT 

12 

CRITICAL  CHEMICAL  THREAT 

CRCHMT 

12 

CRITICAL  SITUATION  MASK 

CRSMSK 

12 

Figure  11-14.  Operation  Parameter  Block  Structure  (Continued) 


II -40 


THE  BDM  CORPORATION 


b)  Appraisal  Weighting  Factors 

Weights  reflecting  the  relative  importance  of 
specific  attributes  of  a  developed  operation  --  role  structure  admissi¬ 
bility,  deployment  acceptability,  kernel  viability,  and  resource  feasi¬ 
bility  —  to  the  overall  desirability  of  the  operation.  Used  to  aggregate 
detailed  appraisals  of  these  attributes  into  an  appraisal  of  overall  opera¬ 
tion  desirability. 

•  Range:  0.00  -  5.00 

•  Input  Format:  Real 

2)  Operation  Appraisal  Minimum  Levels 

Minimum  acceptable  limits  on  attributes  of  a  developed 
operation  —  role  structure  admissibility,  deployment  acceptability,  kernel 
viability,  resource  feasibility,  and  overall  desirability.  If  appraisals 
of  these  attributes  exceed  the  specified  minimum  levels,  the  developed 
operation  is  judged  acceptable  and  may  be  implemented  without  considering 
any  other  concepts.  An  unacceptable  appraisal  of  any  of  these  attributes 
may  cause  the  development  of  the  operation  to  be  halted  and  the  cons i dera¬ 
il  tions  to  shift  to  the  next  concept  of  operation. 

•  Range:  0.00  -  5.00 

t  Input  Format:  Real 

3)  Operation  Progress  Appraisal  Information 
These  information  elements  represent  various  thresholds 

used  in  qualitatively  appraising  the  progress  of  an  ongoing  operation. 

a)  Operation  Progress  Thresholds 

Upper  and  lower  thresholds  which  define  normal 
("ok")  progress  of:  (1)  the  overall  forward  operation,  and  (2)  the  kernel 
operation  (consisting  only  of  key  roles).  Above  the  upper  thresholds, 
progress  is  considered  exceptionally  good  ("good");  below  the  lower  thres¬ 
holds,  progress  is  considered  exceptionally  poor  ("poor"). 

•  Range:  0-10  (10  =  success) 

•  Input  Format:  Integer 
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b)  Advance-to-Next- Phase  Threshold 

The  minimum  fraction  of  forward  roles  (weighted  by 
their  role  weights)  which  must  be  ready  to  advance  to  the  next  phase  of 
their  individual  operations  before  the  overall  operation  can  be  advanced  as 
a  whole  to  its  next  phase. 

•  Range:  000  -  1.00 

•  Input  Format:  Real 

4)  Operation  Progress  Action  Information 

These  information  elements  represent  basic  actions  to 
be  taken  under  various  combinations  of  forward  operation  progress  ("good", 
"ok",  or  "poor")  and  kernel  operation  progress  ("good",  "ok",  or  "poor")  — 
joint  progress  states.  Two  types  of  actions  are  specified:  (1)  operations 
development  actions,  and  (2)  weapons  employment  actions.  The  actions  are 
specified  by  strings  of  flags,  one  for  e^ch  type  of  action.  A  pair  of  flag 
strings  must  be  provided  for  each  of  the  nine  possible  joint  progress 
states  (forward  good/kernel  good,...  forward  poor/kernel  poor). 

a)  Operations  Development  Actions 

Possible  operations  development  actions  which  may 
be  specified  as  the  response  to  a  particular  joint  progress  state  are:  (1) 
advancing  the  overall  operation  to  its  next  phase;  (2)  committing  reserves 
in  the  on-going  operation,  (3)  adjusting  resource  allocations  in  the 
on-going  operation;  and,  (5)  developing  a  new  operation.  Implementation  of 
all  but  the  first  action  may  be  left  to  the  discretion  of  the  development 
process  themselves  or  may  be  "forced".  Multiple  actions  may  also  be  speci¬ 
fied  provided  that  no  intermediate  actions  are  forced. 

g 

•  Range:  2  combinations  may,  in  principle,  be  specified 

•  Input  Format:  {<A0V-NXT- PHASE/ 

C0MMIT-RESRVS/IMPL-C0MMIT/ 
ADJUST-RESOURCE/IMPL- ADJUST/ 
M0DIFY-0PN/IMPL-M0D/ 

DEVEL0P-NEW/IMPL-NEW> , } 
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b)  Weapons  Employment  Actions 

Possible  weapons  employment  actions  which  may  be 
specified  as  the  response  to  a  particular  joint  progress  state  are:  (1) 
consider  employment  of  conventional  weapons  (interdiction);  (2)  consider 
employment  of  nuclear  weapons;  and  (3)  consider  employment  of  chemical 
weapons.  Note  that  the  action  is  merely  to  consider  employment  —  consi¬ 
deration  need  not  result  in  an  employment.  Any  or  all  of  these  actions  may 
be  specified. 

•  Range:  23  distinct  combinations  may  be  specified 

•  Input  Format:  {<CONVEN/NUC/CHM>,} 

5)  Critical  Situation  Diagnosis  Information 

These  information  elements  represent  thresholds  on 
various  situation  information  elements  which  define  critical  conditions. 
Also  included  is  a  critical  situation  mask  which  is  used  in  assessing  which 
critical  conditions  constitute  a  "critical  situation". 

a)  Critical  Operation  Progress  Thresholds 
Thresholds  on  forward  and  kernel  operation  pro¬ 
gress  below  which  the  corresponding  operation  is  in  a  critical  condition. 

•  Range:  0-10 

•  Input  Format:  Integer 

b)  Critical  Operation  Failure  Thresholds 
Fractions  of  roles  in  the  forward  and  kernel 

operations  (weighted  by  their  role  weight)  whose  individual  operations  have 
failed.  If  more  than  this  fraction  has  failed,  the  corresponding  operation 
is  in  a  critical  condition. 

t  Range:  0.00  -  1.00 

•  Input  Format:  Real 

c)  Critical  Fractional  Strength 

Fraction  of  nominal  full  or  TOE  strength  below 
which  the  overall  force  is  in  a  critical  condition. 

•  Range:  0.00  -  1.00 

•  Input  Format:  Real 
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d)  Critical  Unit  Balance 

Threshold  on  detailed  unit  balance  below  which  the 
overall  force  is  in  a  critical  condition. 

•  Range:  0.00  -  40.00 

•  Input  Format:  Real 

e)  Critical  Threat 

Thresholds  on  nuclear  and  chemical  threat  indices 
above  which  the  overall  force  is  in  a  critical  condition. 

0  Range:  0.00  -  40.00 

•  Input  Format:  Real 

f)  Critical  Situation  Mask 

A  string  of  flags  indicating  which  of  the  ground 

operations  development  actions  should  be  considered  in  a  critical  situation 

(i.e.,  when  one  or  more  of  the  critical  conditions  defined  above  exist). 

May  be  used  to  eliminate  certain  minimal -impact  actions  (such  as  adjusting 

resources)  in  critical  situation. 

a 

•  Range:  2  combinations  may,  in  principle,  be  specified 

•  Input  Format:  {<ADV-NXT-PHASE/ 

C0MMIT-RESRVS/IMPL-C0MMIT/ 

ADJUST-RESOURCE/IMPL-ADJUST/ 

MODIFY-OPN/IMPL-MOD/ 


DEVEL0P-NEW/IMPL-NEW> , } 
d.  Resource  Management  Information 

One  important  form  of  guidance  provided  in  a  concept  of 
operation  concerns  that  utilization  of  resources.  Certain  resource  manage¬ 
ment  parameters  are  contained  in  the  Resource  Management  block  having  the 
structure  presented  in  Figure  11-15.  The  line: 

'RESOURCE  MANAGEMENT' 


initiates  the  procedure  to  receive  the  resource  management  inputs. 

It  will  be  noted  that  of  the  various  information  elements 


contained  in  the  resource  management  block,  only  the  reservation  scaling 
factors  for  the  various  types  of  weapons  are  input.  Each  reservation 
scaling  factor  reflects  the  relative  importance  of  discretionary  control  of 
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the  corresponding  resource  by  the  C  I  element.  During  operations  develop¬ 
ment,  reservation  scaling  factors  are  applied  to  "operational  norm"  reser- 
vation  factors  (from  the  developing  Cl  elements'  SOP  information  --  see 
Section  A. 2. a  (1),  above)  to  determine  reservations  of  the  various 
resources. 

•  Range:  0.00  -  10.00 

•  Input  Format:  Real 

Additional  inputs  related  to  resource  management  --  in 
particular,  the  allocation  of  resources  among  subordinates  --  are  contained 
in  the  resource  allocation  blocks  associated  with  the  roles  in  the  opera¬ 
tion  (See  Section  II.C.2.g.(3),  below.). 

e.  Operations  Structure 

The  "heart"  of  a  concept  of  operation  is  its  operation 
structure.  It  is  in  the  operation  structure  that  the  roles,  phases,  and 
operations  of  the  concept  are  characterized.  These  various  operation 
components  are  linked  together  into  a  matrix- like  structure  as  shown  in 
Figure  11-16.  Procedures  to  input  these  blocks  or  "nodes"  will  be  dis¬ 
cussed  in  the  following  sections.  These  procedures  are  initiated  by  the 
1  ine: 

'OPERATION  STRUCTURE' 

This  creates  an  Operation  Structure  block  having  the  structure  portrayed  in 
Figure  11-17.  Note  that  none  of  its  information  elements  are  direct 
inputs.  Rather  they  provide  a  repository  for  accessing  references,  (i.e., 
pointers)  to  the  various  role  blocks,  phase  blocks  and  other  elements  which 
make  up  the  operation  structure.  The  operation  structure  block  is,  in 
effect,  the  "root"  of  the  operation  structure. 

f.  Phases 

The  phases  of  a  concept  of  operation  characterize  its 
progress  over  time  in  the  form  of  specific  operational  "milestones".  The 
overall  phasing  of  a  concept  is  represented  by  a  list  of  phase  blocks 
having  the  structure  shown  in  Figure  11-18.  The  list  is  created  by 
sequentially  inputing  appropriate  phase  blocks.  Each  phase  block's  inputs 
must  be  preceded  by  the  line 

"PHASE  i' 


(LINK  TO  NEXT  PHASE) 
(LINK  TO  OPERATION  NODE) 


Figure  11-16.  Operation  Structure 


iS.V 


I 


PHASE  BLOCK  (PHSBLK) 


BASIC  PHASE  INFORMATION 


PHASE  NUMBER 

PHSNUM 

4 

PHASE  TYPE 

PHSTYP 

3 

PHASE  CONTROL  INFORMATION 


■  *  ra  — 


*-X.  -Hf  i  «_  j  _ 


STRUCTURE  INFORMATION 


Figure  11-18.  Phase  Block  Structure 
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for  some  integer  i  representing  the  ordinal  number  of  that  phase  relative 
to  the  comtemplated  phase  execution  sequence.  The  specific  inputs  will  now 
be  discussed. 


itself. 


1 )  Basic  Phase  Information 

These  information  elements  characterize  the  phase 


a)  Phase  Number 

The  ordinal  number  of  the  phase  relative  to 
the  expected  sequence  of  execution  of  all  phases  in  the  concept;  entered 
via  the  ' PHASE  i 1  line. 

b)  Phase  Type 

An  indication  of  the  type  of  the  phase  (e.g.  , 
"set-up"  vs  "advance-to-contact" ,  etc.).  (Not  presently  used  by  the  model.) 

•  Range:  0-7 

•  Input  Format:  Integer 

2)  Phase  Control  Information 

These  information  elements  represent  expected  and 
actual  progress  in  the  execution  of  the  phase.  They  are  not  input,  but  are 
rather  set  during  execution  of  an  operation  (in  local  copies  of  the  phase 
block. ). 


g.  Roles 

The  roles  of  a  concept  of  operation  repre. ent  the  basic 
functions  to  be  carried  out  by  the  force  elements  involved  in  the  concept. 
Individual  roles  are  represented  by  Role  blocks  having  the  structure  pre¬ 
sented  in  Figure  11-19.  Associated  with  each  role  is  a  sequence  of  indi¬ 
vidual  operation  blocks  correlated  with  the  phase  blocks  and  prescribing 
what  that  role  is  to  be  doing  in  each  phase  contemplated  in  the  concept. 
Also  associated  with  each  role  is  guidance  concerning  the  relative  priority 
of  that  role  for  the  various  types  of  resources.  Finally,  it  is  necessary 
to  characterize  certain  distinguished  groups  of  roles  (key  roles,  forward 
roles,  default  roles),  and  to  establish  operational  associations  between 
certain  roles. 
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ROLE  BLOCK 

(ROLBLK) 


iHrfattl  T  l.k  I’ll  1 1  ■  I 


BASIC  ROLE  INFORMATION 


ROLE  DESIGNATOR 
ROLE  TYPE 


ROLDES 

ROLTYP 


ROLE  WEIGHT 


ROLE  ACTOR  CRITERIA 


ROLE  OPERATION  INFORMATION 


ROLEWT 


FORCE  ELEMENT  ACTOR  TYPE 

ACTYPE 

3 

FORCE  ELEMENT  RELATIVE  POSITION 

RELPSN 

3 

DESIRED  FRACTIONAL  STRENGTH 

FRASTR 

7 

DESIRED  FORCE  BALANCE 

BALDES 

12 

•TIFFLAMHlNfi'  CIMT^ 

SECTOR  WIDTH  IN  PLANNING  GRID  I  SECWID 


•  :s;v 


ASSOCIATE  ROLE  INFORMATION 


:=:;::===r: 


ii.v; 


4  ■  l«JMi  -Jt 


ACTOR  INFORMATION 


Figure  11-19.  Role  Block  Structure 
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To  initiate  the  procedures  for  role  inputs,  the  line: 

'ROLE  =  |[  NAME  |C 

must  precede  all  inputs.  This  is  followed  by  Role  block  inputs  (subsection 
(1),  below),  corresponding  operation  block  inputs  (subsection  (2),  below) 
and  resource  allocation  block  inputs  (subsection  (3),  below).  Finally  role 
characterizations  and  associations  are  established  (subsection  (4),  below). 
In  naming  roles,  it  is  natural  to  use,  e.g.,  "MAIN  ATTACKER"  or  "GENERAL 
RESERVE"  in  several  different  operations.  However  this  would  violate  the 
requirement  that  a  single  name  refer  to  only  one  block.  Thus,  it  is 
suggested  that  an  abbreviation  of  the  operation  name  (e.g.,  'ENV  for 
envelopment)  be  attached  to  common  names  (e.g.  ,  MAIN  ATTACKER/ENV). 

1 )  Role  Block  Inputs 

Inputs  to  the  Role  block  presented  in  Figure  11-19  are 
described  in  this  subsection. 

a)  Basic  Role  Information 

These  information  elements  concern  the  nature  of 
the  role  and  its  relative  importance  in  the  operation. 

!•  Role  Designator 

An  integer  which  uniquely  designates  the  role 
within  the  operation.  (Not  presently  used  in  the  model). 

•  Range:  0-15 

•  Input  Format:  Integer 

2.  Role  Type 

An  integer  which  reflects  the  type  of  the 
role  (not  presently  used  by  the  model), 
t  Range:  0-63 

t  Input  Format:  Integer 

3.  Role  Type  Indicators 

Flags  indicating  whether  the  role  is  a  key 
role,  associate  role,  and  or  forward  role.  They  are  not  input  directly, 
but  are  rather  established  by  means  of  "Role  Characterization  Statements" 
as  discussed  below  (Section  C.2.g. (4). (a). 
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4.  Role  Weight 

An  indication  of  the  relative  importance  of 

the  role  within  the  overall  operation--used  to  reflect  this  importance  in 
2 

various  C  I  processes. 

•  Range:  0.00  -  5.00 

•  Input  Format:  Real 

b)  Role  Actor  Criteria 

These  information  elements  represent  attributes 
which  are  required  or  desired  of  any  force  element  assigned  to  fill  the 
role. 

1_.  Force  Element  Actor  Type 

The  type  of  force  element  required  to  fill 

the  role. 

•  Range:  N/A 

•  Input  Format:  GND-CBT/GND-FIRE-SPT/ 

GND-CBT-SPT/GND-SVC-SPT/ 

AIR-CBT/AIR-FIRE-SPT/ 

AIR-CBT-SPT/AIR-SVC-SPT 

2.  Force  Element  Relative  Position 

A  set  of  three  flags  specifying  the  relative 
position  ("left",  "interior",  or  "right")  required  of  a  force  element  to 
fill  the  role.  Any  or  all  flags  may  be  set. 

3 

•  Range:  2  distinct  combinations  may  be  specified 

•  Input  Format:  {<LEFT/INTERI0R/RIGHT> , } 

3.  Desired  Fractional  Strength 

A  lower  limit  on  the  fractional  strength 
desired— not  required— of  a  force  element  (with  respect  to  its  nominal 
"full"  or  "TOE"  strength)  in  order  to  properly  fill  the  role. 

•  Range:  0.00  -  1.00 

•  Input  Format:  Real 

4.  Desired  Force  Balance 

A  lower  limit  on  the  detailed  unit  balance 
desired— not  required— of  a  force  element  in  order  to  properly  fill  the 
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•  Range:  0.00  -  40.00 

•  Input  Format:  Real 


c)  Role  Operation  Information 

These  information  elements  represent  various 
aspects  of  the  operations  of  the  role  within  the  overall  operation.  Some 
are  set  during  operations  development  (e.g. ,  "Lateral  Development  in 
Planning  Grid")  and  some  provide  for  references  to  blocks  created  later  in 
the  input  process  (e.g. ,  "Active  Operation  Pointer"). 

2-  Sector  Width  in  Planning  Grid 

The  desired  sector  width  within  the  overall 


standard  planning  grid  to  be  covered  by  a  nominally  "full"  strength  force 
element  filling  this  role.  Adjusted  during  operations  development  to 
account  for  actual  strength. 

•  Range:  0-100  planning  grid  units 

•  Input  Format:  Integer 

d)  Associate  Role  Information 

These  information  elements  represent  various 
operational  associations  between  different  roles  in  the  operation.  They 
are  not  input  directly,  but  are  rather  established  by  means  of  Role  Asso¬ 
ciation  Statements  as  discussed  below  (Section  C. 2. g. (4). (b). ). 

e)  Actor  Information 

These  information  elements  specify  a  particular 
force  element  assigned  to  fill  the  role.  They  are  not  input  at  all,  but 
are  rather  set  during  operations  development  activities  (in  local  copies  of 
the  role  block). 


2)  Role  Operations 

A  role's  individual  operations  in  a  concept  of  opera¬ 
tion  are  represented  by  a  sequence  of  Operation  blocks  having  the  structure 
presented  in  Figure  11-20.  One  operation  block  must  be  provided  for  each 
phase  in  the  operation.  The  line: 

'OPERATION  IN  PHASE  i' 

initiates  the  procedure  to  input  the  role's  operation  block  for  the  ith 


phase  in  the  concept.  Specific  inputs  will  now  be  described. 
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a)  Basic  Operation  Information 

These  information  elements  characterize  basic 
aspects  of  the  operation.  They  are  not  directly  input,  but  are  rather 
established  by  the  role  and  phase  contexts  in  which  the  operation  block  is 

created.  (The  "Operation  Ordered  Flag"  is  used  in  the  implementation  of  an 

* 

operation  developed  under  the  concept.) 

b)  Mission/Qbjective  Information 

These  information  elements  characterize  the 
mission  and  objective  of  the  operation  in  generalized  form. 

L  Mission 

An  integer  code  designating  the  particular 
mission  to  be  accomplished  in  performing  the  operation  specified  by  the 
operation  block. 

•  Range:  0-63 

•  Input  Format:  Integer 

2.  Objective  Depth  Code 

A  code  indicating  whether  "Objective  Depth 
Position"  information  (see  below)  is  to  be  interpreted  as:  (1)  an  absolute 
depth  in  the  standard  planning  grid,  or  (2)  a  relative  depth  in  planning 
grid  units  with  respect  to  the  absolute  depth  of  a  related  role's 
objective. 

•  Range:  N/A 

•  Input  Format:  ABSOLUTE/RELATIVE 

3.  Objective  Depth  Direction 

A  code  indicating  whether  a  relative  depth 
(see  above)  is  to  be  interpreted  as  ahead-of  or  behind  the  absolute  depth 
of  the  related  role's  objective.  (Applies  only  when  the  depth  code  = 
RELATIVE.) 

•  Range:  N/A 

•  Input  Format:  AHEAD-OF/BEHIND 

4.  Objective  Depth  Position 

A  depth  in  the  standard  planning  grid  units 
used  in  setting  the  depth  of  the  operation's  objective.  May  be  interpreted 
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as  an  absolute  depth  or  a  relative  depth  ahead-of  or  behind  a  related 
role's  objective  (depending  on  the  depth  code  and  depth  direction  as  dis¬ 
cussed  above). 

•  Range:  0  -  200  planning  grid  units 

•  Input  Format:  Integer 

5.  Objective  Lateral  Code 

A  code  indicating  whether  "Objective  Lateral 
Position"  information  (see  below)  is  to  be  interpreted  as:  (1)  an  absolute 
lateral  position  in  the  standard  planning  grid,  (2)  a  displacement 
laterally  from  the  role's  initial  lateral  deployment  line,  (3)  a  relative 
lateral  position  with  respect  to  the  lateral  position  of  a  related  role's 
objective,  or,  (4)  an  open  lateral  position  to  be  set  based  on  the  needs  of 
the  operation. 

t  Range:  N/A 

•  Input  Format:  ABSOLUTE/DISPLACMENT/ 

RELATIVE/OPEN 

6.  Objective  Lateral  Direction 

A  code  indicating  whether  a  displacement  or 
relative  lateral  position  is  to  be  interpreted  as  left-of  or  right-of  the 
reference  position  (initial  lateral  deployment  or  lateral  position  of 
related  role's  objective).  Applies  only  when  lateral  code  =  DISPLACEMENT 
or  RELATIVE. 

•  Range:  N/A 

•  Input  Format:  LEFT-0F/RIGHT-0F 

7.  Objective  Lateral  Position 

A  lateral  position  (or  distance)  in  standard 
planning  grid  units  used  in  setting  the  lateral  position  of  the  operations 
objective.  May  be  interpreted  as  an  absolute  lateral  position,  a  dis¬ 
placement,  or  a  relative  position  left-of  or  right-of  a  reference 
position  (depending  on  the  lateral  code  and  lateral  direction  as  discussed 
above). 

•  Range:  0  -  100  planning  grid  units 

•  Input  Format:  Integer 
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c)  Operation  Control  Information 

These  information  elements  represent  various 
aspects  of  executing  and  controlling  an  operation.  Most  are  set  during 
operation's  development  or  execution/control  processes  and  are,  accor¬ 
dingly,  not  input.  Guidance  concerning  sector  width  is  input,  however. 

1-  Sector  Width 

The  desired  sector  width  within  the  overall 
standard  planning  grid  to  be  covered  by  a  "full"  strength  force  element 
conducting  this  operation.  Adjusted  during  operation  development  to 
account  for  actual  strengths. 

•  Range:  0-100  planning  grid  units 

•  Input  Format:  Integer 

d)  Structure  Information 

These  information  elements  represent  accessing 
relationships  from  the  operation  block  to  other  operation  blocks  and  to  the 
role  which  carries  it  out.  They  are  not  input,  but  rather  derive  from  the 
input  structuring. 

3)  Role  Resource  Allocation 

Guidance  concerning  the  relative  priority  of  a  role  for 
various  types  of  resources  is  represented  in  an  Allocation  block  having  the 
structure  presented  in  Figure  11-21.  Inputs  to  this  block  must  be  preceded 
by  the  line: 

'RESOURCE  ALLOCATION' 

It  will  be  noted  that  of  the  various  information 
elements  contained  in  the  resource  allocation  block  structure,  only  the 
scaling  factors  for  the  various  types  of  resources  are  input.  Each  scaling 
factor  reflects  the  relative  priority  of  the  corresponding  role  with 
respect  to  allocations  of  that  resource  type.  During  operations  develop¬ 
ment,  the  scaling  factors  are  applied  to  "operational  norm"  allocations  of 
the  resources  (from  the  developing  C  I  element's  SOP  information— see 
Section  A.  2. a. (3),  above)  to  determine  desired  allocations  to 
subordinates. 

•  Range:  0.00  -  10.00 

•  Input  Format:  Real 
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RESOURCE  ALLOCATION  BLOCK 


(ALLBLK) 


AIR  SUPPORT  ALLOCATION 


WEAPONS  ALLOCATION 


NUC  ALLOCATION  SCALING  FACTOR 


CHEM  ALLOCATION  SCALING  FACTOR 


SERVICE  SUPPORT  ALLOCATION 


SUP  ALLOCATION  SCALING  FACTOR 


REPL  ALLOCATION  SCALING  FACTOR 


CAS  ALLOCATION  SCALING  FACTOR 

□ 

CASALS 

r 

INT  ALLOCATION  SCALING  FACTOR 

n 

INTALS 

n 

NUCALS 


CHMALS 


SUPALS 


RPLALS 


Figure  11-21.  Resource  Allocation  Block  Structure 
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4)  Role  Characterizations  and  Associations 

At  this  stage  in  the  role  input  process,  individual 
(named)  roles  have  been  created.  It  is  now  necessary  to  structure  this  set 
of  roles  in  two  ways.  First,  certain  special  types  of  roles  must  be  dis¬ 
tinguished  (and  made  accessible  via  the  operation  structure  block)  for  use 
in  the  operations  development  processes.  Second,  certain  associations 
("left",  "right",  or  "reserve")  between  roles  may  be  required  to  properly 
reflect  operational  relationships  within  the  concept.  The  result  of  this 
structuring  is  a  system  of  roles. 

To  create  such  a  system,  the  existence  of  roles  as 
named  components  is  exploited.  The  names  can  be  used  in  "role  characteri¬ 
zation  statements"  and  "role  association  statements"  which  prescribe  the 
necessary  structuring.  These  statements  must  be  preceded  by  the  line: 

ROLE  STRUCTURE 

to  initiate  the  proper  processing. 

a)  Role  Characterization  Statements 

Refering  back  to  the  operation  structure  block 
portrayed  in  Figure  11-17,  above,  it  will  be  noted  that  information 
elements  are  provided  for  references  to  various  special  types  of  roles: 
"key  roles",  "forward  default  role",  "non-forward  combat  support  role",  and 
so  forth.  These  distinguished  roles  (or  sets  of  roles)  play  a  special  part 
in  the  operations  development  process. 

To  "attach"  appropriate  roles  to  these  references, 
role  characterization  statements  are  used.  Role  characterization  state¬ 
ments  have  the  form: 

'  ||name||  is  <oescriptor>  role1 

where  ||  NAME ||  refers  to  a  specific  role,  and  <DESCRIPTOR>  is  defined  as: 

<DESCRIPTOR>  =  KEY/FORWARD  [DEFAULT]/ 

NONFORWARD  CBT  DEFAULT/ 

NONFORWARD  FIRESPT  DEFAULT/ 

NONFORWARD  CBTSPT  DEFAULT/ 

NONFORWARD  SVC  SPT  DEFAULT/ 
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The  result  of  such  a  role  characterization  statement  is  to  link  the  named 
role  into  the  appropriate  slot  in  the  operation  structure  block.  In  addi¬ 
tion,  certain  role  type  indicator  flags  in  the  role  block  itself  may  be  set 
in  processing  a  role  characterization  statement. 

b)  Role  Association  Statements 

Referring  back  to  the  role  block  portrayed  in 
Figure  11-19,  above,  it  will  be  recalled  that  the  Associate  Role  informa¬ 
tion  elements  represented  operational  linkages  among  different  roles.  To 
create  such  associations,  role  association  statements  are  used.  Role 
association  statements  have  the  form. 

'ASSOCIATION  TYPE>  ASSOCIATE  OF  ||  NAME-j  ||  IS  ||  NAME^I  1 
where  ||  NAME-j  ]|  and  |(  NAME2 1|  refer  to  specific  roles  and  ASSOCIATION 
TYPE>  is  defined  as: 

ASSOCIATION  TYPE>  =  LEFT/RIGHT/RESERVE 
The  result  of  such  a  role  association  statement  is  to  create  a  link 
(pointer)  of  the  appropriate  type  (left,  right,  or  reserve  associate)  from 
the  role  block  ||  NAME-j  |l  to  the  role  block  ||NAME2II  . 

h.  Individual  Concept  Input  Terminator 

The  inputs  to  each  individual  concept  must  be  termined  by 

the  line 

END  CONCEPT 

before  another  concept  can  be  created  by  further  inputs. 

D.  CREATE  NAMED  WEAPONS  EMPLOYMENT  CONCEPT  COMPONENTS 

2 

Weapons  employment  concepts  guide  C  I  elements  as  they  attempt  to 

develop  weapons  employments  in  support  of  their  operations.  A  weapons  em- 

2 

ployment  concept  provides  generalized  guidance  to  a  Cl  element  concerning 

2 

one  approach  to  employing  weapons;  a  C  I  element  uses  this  guidance  by 

"fitting"  or  "specializing"  the  employment  concept  to  the  specific  features 

of  the  situation  it  faces:  quantity  and  type  of  weapons  available,  targets 

acquired,  and  so  forth.  Of  course,  a  given  employment  concept  may  or  may 

2 

not  be  appropriate  in  a  particular  situation.  Thus,  each  C  I  element  must 


n 


> 
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be  provided  with  several  weapons  employment  concepts.  (See  the  Modeling 
Description,  Volume  V,  Chapter  V,  and  the  Software  Description,  Volume  III, 
Chapter  V,  for  further  discussion.) 

As  was  discussed  in  the  Software  Description,  Volume  II,  Chapter  II, 

2 

Section  E,  weapons  employment  concepts  provided  to  each  C  I  element  are 
organized  as  ordered  sets.  A  particular  set  represents  concepts  generally 
applicable  in  a  given  broadly  defined  situation.  At  present,  four  sets  of 
weapons  employment  concepts  are  provided:  (1)  a  singleton  set  for  employ¬ 
ment  of  conventional  weapons  (interdiction)  under  normal  nuclear/chemical 
threat;  (2)  a  singleton  set  for  employment  of  conventional  weapons  under 
high  nuclear/chemical  threat;  (3)  a  set  for  employment  of  nuclear  weapons; 
and,  (4)  a  set  for  employment  of  chemical  weapons.  Within  each  set,  con¬ 
cepts  are  ordered  in  terms  of  general  doctrinal  preference;  this  guides  the 

2 

order  in  which  the  concepts  are  considered  by  C  l  elements.  Within  the 
model,  this  organization  is  implemented  by  means  of  a  directory  of  weapons 
employment  concept  as  portrayed  in  Figure  11-22.  Each  entry  in  the  direc¬ 
tory  is  a  reference  to  a  particular  list  of  employment  concepts  corres¬ 
ponding  to  the  concept  sets  noted  above.  Within  each  list,  doctrinal 
preference  is  implemented  by  the  accessing  sequence  of  the  list:  the  first 
employment  concept  on  the  list  is  the  most  preferred,  the  second  is  the 

next-most  preferred,  and  so  on. 

2 

Each  INWARS  C  I  element  at  echelons  above  division  must  be  provided 
with  access  to  a  weapons  employment  concept  directory  through  its  UOS. 

Like  concepts  of  operation,  weapons  employment  concepts  have  been  designed 

2 

to  be  independent  of  echelon  within  the  EAD  C  l  elements.  Thus,  two  named 
weapons  employment  directories  must  generally  be  created--one  for  each 
side. 

To  initiate  the  creation  of  named  weapons  employment  directories,  the 

line: 

'EMPLOYMENT  CONCEPT  DIRECTORY' 

must  precede  all  directory  specifications  and  employment  concept  inputs. 
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1.  Create  Named  Weapons  Employment  Concept  Directory 

To  initiate  the  creation  of  a  specific  named  weapons  employment 
concept  directory,  the  line: 

'DIRECTORY  =  1|NAME||' 

must  precede  the  list  specifications  and  inputs  for  the  specific  employment 
concepts  to  be  included  in  the  directory.  These  concept  blocks  can  be 
created  in  appropriate  lists  as  discussed  in  the  next  section.  As  they  are 
created,  references  to  these  lists  are  inserted  into  the  named  directory  in 
accordance  with  the  list  type  specification. 

2.  Create  Weapons  Employment  Concepts 

In  the  context  of  a  specific  named  weapons  employment  concept 
directory,  appropriate  lists  of  employment  concepts  must  be  created  for: 

(1)  employment  of  conventional  weapons  under  normal  nuclear/chemical 
threat; 

(2)  employment  of  conventional  weapons  under  "high"  nuclear/chemical 
threat; 

(3)  employment  of  nuclear  weapons;  and,  (4)  employment  of  chemical 
weapons. 

To  initiate  creation  of  any  of  these  lists,  the  line: 

*  <  LI  ST  TYPE  KEYWORDS 
where: 

<LIST  TYPE  KEYW0RD>  =  CONVENTIONAL  NORMAL/ 

CONVENTIONAL  HIGH/ 
NUCLEAR/CHEMICAL 

must  precede  the  inputs  for  the  specific  employment  concepts  to  be 
included.  The  list  type  keyword  specifies  where  a  reference  to  the  forth¬ 
coming  list  is  to  be  inserted  into  the  Employment  Concept  Directory. 

To  create  the  list  specified  by  the  list  type  keyword,  appro¬ 
priate  inputs  are  then  made  for  each  weapons  employment  concept  to  be 
included  in  the  list.  Weapons  employment  concepts  have  the  structure 
portrayed  in  Figure  11-23.  The  specific  inputs  will  now  be  discussed. 


EMPLOYMENT  CONCEPT  BLOCK 


a* 


(EMPBLK) 


SUITABILITY  INFORMATION 


LOWEST  APPLICABLE  ECHELON 
APPLICABLE  JUSTIFICATIONS 


APPRAISAL  INFORMATION 


LOWECH 

ADJUST 


EXPECTED  SUBORDINATE  EMPLOYMENT  PRIORITY  EXPSEP 


MINIMUM  APPROPRIATENESS 


OVERALL  EMPLOYMENT  INFORMATION 


MINAPP 


DISCRETIONARY  CONTROL  FRACTION  |  DCFRAC 
NATIONAL  TERRITORY  CONSTRAINT  INDICATOR  NTCONF 
COLLATERAL  DAMAGE  CONSTRAINT  INDICATOll  CDCONF 


UTILIZATION  INTERVAL 


UTILTM 


EMPLOYMENT  INFORMATION  FOR  TARGET  TYPE  0 


BASIC  TARGET  PRIORITY 
DESIRED  EFFECT  LEVEL 


BASPRI 

DESEFF 


EMPLOYMENT  INFORMATION  FOR  TARGET  TYPE  7 


BASIC  TARGET  PRIORITY 
DESIRED  EFFECT  LEVEL 


BASPRI 

DESEFF 


3 

12 


3 
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7 

1 

1 

18 


3 

2 


3 
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Figure  11-23.  Employment  Concept  Structure 
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a.  Basic  Employment  Concept  Information 

This  information  element  provides  a  reference  to  the  name  of 
the  employment  concept.  The  name  itself  is  entered  as  a  string  of 
characters. 

•  Range:  N/A 

•  Input  Format:  Character  String 

b.  Suitability  Information 

These  two  information  elements  represent  the  conditions 

under  which  the  employment  concept  will  be  judged  suitable  for  application 

2 

by  the  C  I  element. 

1)  Lowest  Applicable  Echelon 

The  lowest  echelon  of  command  which  can  develop  weapons 
employments  utilizing  the  concept.  Used  to  restrict  the  applicability  of 
employment  concepts  to  certain  higher  echelon  commands. 

•  Range:  N/A 

•  Input  Format:  THEATER/ 

ARMY  GROUP/FRONT/ 

CORPS/ARMY/ 

DIVISION/ 

BRIGADE/REGIMENT 

2)  Applicable  Justifications 

A  string  of  flags  representing  the  situations  under 
which  the  employment  concept  may  be  utilized.  The  possible  situations  are: 
(1)  Critical  Forward  Operation  Progress,  (2)  Critical  Forward  Operation 
Failure,  (3)  Critical  Kernel  Operation  Progress,  (4)  Critical  Kernel  Opera¬ 
tion  Failure,  (5)  Critical  Strength,  (6)  Critical  Unit  Balance,  (7) 
Critical  Nuclear  Threat,  and,  (8)  Critical  Chemical  Threat.  Any  or  all  of 
these  may  be  flagged  as  applicable  justifications.  Thus,  applicable  justi¬ 
fications  may  be  used  to  restrict  the  utilization  of  particular  employment 
concepts  to  certain  specific  sets  of  situations. 

•  Range:  N/A 

•  Input  Format:  {<FWD  PROGRESS/FORWARD  FAIL/ 

KERNEL  PROGRESS/KERNEL  FAIL/ 


n'.  t v;  i. .  •*.  ~  v:  '.w.  ••.  ■-.  .  •' . 
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STRENGTH/UNIT  BALANCE/ 

NUCLEAR  THREAT/CHEMICAL  THREAT> , } 

c.  Appraisal  Information 

These  two  information  elements  concern  the  appraisal  of  an 
employment  plan  developed  under  the  given  employment  concept. 

1 )  Expected  Subordinate  Employment  Priority 

The  expected  priority  of  targets  against  which  weapons 
apportioned  to  subordinates  will  be  employed.  Used  in  assessing  the 
expected  contribution  of  weapons  apportioned  to  subordinates  to  the  overall 
impact  of  an  employment  plan. 

•  Range:  0  -  7  (7  =  highest  priority) 

•  Input  Format:  Integer 

2)  Minimum  Appropriateness 

The  minimum  acceptable  level  of  the  appropriateness 
appraisal  (expected  priority  of  engaged  targets  and  subordinate  apportion¬ 
ment).  Below  this  level,  an  employment  plan  will  be  considered  inappro¬ 
priate  and  will  hence  not  be  acted  on. 

«  Range:  0  -  7  (7  =■  highest  priority) 

•  Input  Format:  Integer 

d.  Overall  Employment  Information 

These  information  elements  represent  guidance  concerning 
certain  features  of  developing  a  weapons  employment  as  a  whole  under  this 
employment  concept. 

1 )  Discretionary  Control  Fraction 

A  fraction  to  be  applied  to  the  total  weapons  available 

for  employment  in  order  to  determine  the  portion  of  weapons  which  may  be 

2 

assigned  directly  against  target  under  the  discretionary  control  of  the  Cl 
element  developing  the  employment.  Remaining  weapons  will  be  apportioned 
among  subordinates  for  their  use.  This  fraction  is  used  to  reflect  the 
degree  to  which  the  implementation  of  an  employment  is  decentralized. 

•  Range:  0.00  -  1.00 

•  Input  Format:  Real 
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2)  National  Territory  Constraint  Indicator 

A  flag  which  indicates  whether  or  not  national  terri¬ 
tory  constraints  are  to  be  considered  in  developing  an  employment  under 
this  concept. 

•  Range:  0,1  (1  =  national  territory  constraints  to  be 

considered) 

•  Input  Format:  Integer 

3)  Collateral  Damage  Constraint  Indicator 

A  flag  which  indicates  whether  or  not  collateral  damage 
constraints  are  to  be  considered  in  developing  an  employment  under  this 
concept. 

•  Range:  0,1  (1  =  collateral  damage  constraints  are  to  be 

considered) 

•  Input  Format:  Integer 

4)  Utilization  Interval 

The  time  interval  within  which  weapons  employed  in 
accordance  with  this  concept  are  to  be  utilized.  Used  to  set  the  utiliza¬ 
tion  interval  for  any  weapons  employment  packages  formulated  in  acting  on 
an  employment  developed  under  this  concept. 

•  Range:  0  -  4000  hours 

•  Input  Format:  Integer 

e.  Target- Related  Employment  Information 

These  information  elements  represent  employment  guidance 
which  is  related  to--and  varies  among-- the  different  target  types.  Within 
the  employment  concept,  these  two  information  elements  are  thus  repeated 
once  for  each  target  (see  Figure  11-23).  Included  here  are  information 
elements  which  prescribe  the  basic  priority  and  effects  to  be  inflicted 
upon  the  various  target  types. 

1)  Basic  Target  Priority 

An  ordinal  indication  of  the  basic  importance  of  the 

given  target  type  relative  to  other  target  types.  It  may  be  modified  in 

developing  an  employment  based  on  the  echelon  of  the  target  (relative  to 

2 

the  echelon  of  the  developing  Cl  element). 
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•  Range:  0  -  7  (7  =  highest  priority; 

0  =  unsuitable  for  targeting  under  this 
concept) 

•  Input  Format:  Integer 

2)  Desired  Effect  Level 

An  indication  of  the  desired  effect  level  to  be  in¬ 
flicted  upon  the  given  target  type  if  engaged  under  this  concept.  It  may 
be  modified  in  developing  an  employment  based  on  operative  weapons  assign¬ 
ment  constraint. 

•  Range:  N/A 

•  Input  Format:  DEGRADE/DISRUPT/DESTROY 

E.  CREATE  NAMED  WEAPONS  PARAMETERS  COMPONENTS 

In  addition  to  the  weapons  employment  concepts  discussed  in  the  pre¬ 
vious  section,  certain  parameters  associated  with  specific  weapons  types 
are  needed  in  the  development  of  a  weapons  employment  plan.  These  para¬ 
meters  concern  requirements  and  constraints  as  well  as  expected  effects  of 
employing  the  corresponding  types  of  weapons. 

Each  weapons  parameter  structure  contains  all  parameters  associated 
with  a  given  type  of  weapons.  Thus,  three  weapons  parameter  structures  are 
required,  one  each  for  conventional  (interdiction),  nuclear,  and  chemical 
weapons.  To  facilitate  accessing,  references  to  these  three  parameter 
structures  are  consolidated  in  a  single  structure— the  weapons  parameters 
directory.  Each  side  would  typically  have  its  own  weapons  parameters 
directory.  However,  there  would  generally  be  no  reason  to  distinguish  the 
parameters  of  weapons  available  to  different  echelons  within  a  side.  Thus, 
two  weapons  parameter  directories  would  typically  provide  a  sufficient 
characterization  of  weapons. 

To  initiate  the  creation  of  named  weapons  parameter  components,  the 

1  ine: 

'WEAPONS  PARAMETER  DIRECTORY' 

must  precede  all  directory  specifications  and  weapons  parameter  inputs. 
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1.  Create  Named  Weapons  Directory 

To  initiate  the  creation  of  a  specific  named  weapons  parameter 
directory,  the  line: 

'DIRECTORY  =  ||  NAMEjj  ' 

must  precede  the  inputs  for  the  parameter  structures  to  be  included  in  the 
directory.  These  parameter  structures  can  then  be  created  as  discussed  in 
the  next  subsection.  As  they  are  created,  references  to  the  parameter 
blocks  are  inserted  into  the  weapons  parameter  directory  whose  structure  is 
portrayed  in  Figure  11-24. 

2.  Create  Weapons  Parameter  Structure 


In  the  context  of  a  specific  named  weapons  parameter  directory, 
one  weapons  parameter  structure  must  be  created  for  each  type  of  weapons— 
conventional  (interdiction),  nuclear,  and  chemical.  The  parameters 
characterizing  each  type  of  weapons  must  be  preceded  by  the  line: 

'WEAPONS  TYPE  =  <INTERDICTION/NUCLEAR/CHEMICAL> ' 

Following  this,  parameter  inputs  for  the  weapons  type  indicated  may  be 
specified.  The  weapons  parameter  structure  consists  of  a  basic  block  of 
parameters  relating  only  to  the  weapons  themselves  together  with  a  list  of 
blocks  containing  parameters  concerning  the  relationship  of  the  given  type 
of  weapons  to  the  various  types  of  targets.  Inputs  to  the  basic  weapons 
parameters  block  are  discussed  in  Section  a,  below;  weapons-target  inputs 
are  then  discussed  in  Section  b. 

a.  Basic  Weapon  Parameters 

Parameters  characterizing  the  given  type  of  weapons  them¬ 
selves  are  contained  in  a  weapons  parameters  block  having  the  form  pre¬ 
sented  in  Figure  11-25.  As  can  be  seen,  it  includes  basic  parameters  and 
national -territory-dependent  parameters.  These  will  now  be  discussed. 

1)  Minimum  Weapons  Assignment 


This  parameter  characterizes  the  smallest  quantity  of 
weapons  of  the  given  type  which  can  be  effectively  assigned  against  a 
single  target. 

e  Range:  0  -  262,000  appropriate  units  (sorties,  kilotons, 
tons) 

•  Input  Format:  Integer 
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WEAPONS  PARAMETERS  BLOCK 

(WPPBLK) 

■ 

BASIC  PARAMETERS 

WEAPONS  TYPE 

WPNTYP 

3 

MINIMUM  WEAPONS  ASSIGNMENT 

MINWPN 

18 

GROSS  STRENGTH  REDUCTION  FACTOR 

GSTRED 

18 

GROSS  EFFECTIVE  COVERAGE  FACTOR 

GEFCOV 

18 

IN-DAY  RESERVATION  FACTOR 

INDARS 

7 

TAR( 

SET  DEPENDENT  PARAMETERS 

PAR/ 

\METERS  FOR  NATIONAL  TERRITORY  0 

MAX  WEAPONS  ASSIGNMENT 

TER00 

18 

• 

• 

• 

- 1 

PARAMETERS  FOR  NATIONAL  TERRITORY  15 


T 


MAX  WEAPONS  ASSIGNMENT 


TER  15 


18 
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2)  Gross  Strength  Reduction  Factor 

The  expected  reduction  in  gross  enemy  strength  resul¬ 
ting  from  a  "typical"  employment  of  one  unit  of  weapons  of  the  given  type 
(sortie,  kiloton,  ton).  Used  for  gross  effects  estimation  in  conjunction 
with  consideration  of  enemy  response  constraints. 

•  Range:  0  -  262,000  strength  units 

•  Input  Format:  Integer 

3)  Gross  Effective  Coverage  Factor 

The  expected  square  kilometers  "covered"— in  the  sense 
of  producing  collateral  damage— as  a  result  of  a  typical  employment  of  one 
unit  of  weapons  of  the  given  type  (sortie,  kiloton,  ton).  Used  for  esti¬ 
mation  of  collateral  damage  in  conjunction  with  consideration  of  collateral 
damage  constraints. 

2 

•  Range:  0  -  262,000  km 

•  Input  Format:  Integer 

4)  In-Day  Reservation  Factor 

A  factor  reflecting  the  importance  of  utilizing  weapons 
of  the  given  type  "evenly"  over  a  day.  A  value  of  0.00  indicates  that  any 
weapons  may  be  used  at  any  time  in  the  day;  by  contrast,  a  value  of  1.00 
indicates  that  weapons  may  only  be  used  in  proportion  to  the  time  elapsed 
in  the  day.  This  factor  is  used  only  for  weapons  allocated  on  a  daily  rate 
basis  (e.g. ,  interdiction  sorties/day). 

•  Range:  0.00  -  1.00 

•  Input  Format:  Real 

5)  National  Territory-Dependent  Parameters 

These  information  elements  represent  constraints  on  the 
weapon  type  which  are  related  to— and  vary  among— different  national  terri¬ 
tories.  In  particular,  the  constraint  takes  the  form  of  the  maximum  amount 
of  weapons  which  may  be  assigned  against  a  single  target  located  in  a 
particular  national  territory.  One  such  constraint  is  included  for  each 
national  territory. 

•  Range:  0  -  262,000  appropriate  units  (sorties,  kilotons, 

tons) 

•  Input  Format:  Integer 
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b.  Weapons  Target  Parameters 

In  addition  to  specific  parameters,  the  Weapons  Parameters 
block  contains  a  pointer  reference  to  a  list  of  blocks  containing  para¬ 
meters  characterizing  relationships  between  the  given  type  of  weapons  and 
the  various  target  types.  Each  of  these  Target  Parameters  Blocks  has  the 
structure  presented  in  Figure  11-26  and  concerns  a  specific  type  of  target. 
Within  the  context  established  by  the  'WEAPONS  TYPE  =  INTERDICTION/ 
NUCLEAR/CHEMICAL>'  line,  one  Target  Parameters  Block  must  be  input  for  each 
target  type.  The  input  for  the  ith  target  type  must  be  preceded  by  the 
line: 

TGTTYP  =  i 

The  particular  target  parameters  to  be  imput  will  now  be  discussed. 

1 )  Largest  Targetable  Echelon 

The  largest  echelon  of  the  given  target  type  which  can 
be  effectively  targeted  with  weapons  of  the  given  type, 
e  Range:  0  -  6  (6  =  Theater) 
e  Input  Format:  Integer 

2)  Information  Timeliness  Criterion 

The  maximum  age  of  the  target  information  which  still 
qualifies  the  force  element  as  an  acquired  target  for  the  purposes  of 

engagement  with  the  given  type  of  weapons, 
e  Range:  0  -  4000  hours 

#  Input  Format:  Integer 

3)  Minimum  Hex  Level  Precision  Criterion 

The  maximum  hex  level  in  which  a  target  of  the  given 
type  can  be  located  and  still  qualify  as  an  acquired  target  for  the  pur¬ 
poses  of  engagement  with  the  given  type  of  weapons. 

§  Range:  0-6 

(Level  0:  9.45  km  hexes;  Level  1:  25  km; 

Level  2:  66  km;  Level  3:  137  km;  Level  4:  362  km; 

Level  5:  959  km;  Level  6:  2537  km) 
e  Input  Format:  Integer 
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TARGET  PARAMETERS  BLOCK 

(TPPBLK) 

BASIC  WEAPON -TARGET  PARAMETERS 

TARGET  TYPE 

TGTTYP 

3 

LARGEST  TARGETABLE  ECHELON 

LTGECH 

3 

INFORMATION  TIMELINESS  CRITERION 

INFOCR 

18 

MIN  HEX  LEVEL  PRECISION  CRITERION 

LOCPCR 

4 

MIN  FRACTION  ACQUIRED  CRITERION 

FRACCR 

7 

WEAPON -TARGET  EFFECT  LEVEL  PARAMETERS 

BASIC  WEAPONS  ASSGN  FOR  LEVEL  1 

BASSG1 

18 

BASIC  WEAPONS  ASSGN  FOR  LEVEL  2 

BASSG2 

18 

BASIC  WEAPONS  ASSGN  FOR  LEVEL  3 

BAS3G3 

18 

STR 

UCTURE  INFORMATION 

fc-.-r--:  ...  .  . . = -  ..  

■■■—  ■  l"n —  w 
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4)  Minimum  Fraction  Acquired  Criterion 

The  minimum  fraction  of  an  aggregate  force  element 
which  must  be  "acquired"  to  qualify  the  aggregate  force  element  as  an 
acquired  target  for  the  purposes  of  engagement  with  the  given  type  of 
weapons. 

•  Range:  0.00  -  1.00 

•  Input  Format:  Real 

5)  Basic  Weapons  Assignments 

The  quantity  of  weapons  of  the  given  type  which  must  be 
assigned  against  a  target  of  the  given  type  to  achieve  a  desired  level  of 
effect.  A  separate  basic  weapons  assignment  is  included  in  the  parameter 
block  for  each  of  the  three  possible  desired  effect  levels. 

•  Range:  0  -  262,000  appropriate  units  (sorties,  kilotons, 

tons) 

•  Input  Format:  Integer 
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i;  CHAPTER  III 

EAD  C2I  ELEMENT  UNDERSTANDING  OF  THE  SITUATION  (UOS)  INPUTS 

2 

As  was  noted  in  the  introduction,  inputs  to  the  C  I  processes  consist 

primarily  of  UOS  Information  structures  and  elements.  In  particular,  the 
2 

UOS  of  each  EAD  C  I  element  must  be  created  and  filled  with  certain  infor¬ 
mation,  consisting  principally  of  Fundamental  Knowledge  components  which 
2 

guide  the  EAD  C  I  element  in  its  activities,  but  also  including  information 
needed  to  "initialize"  that  UOS. 

Since  Fundamental  Knowledge  information  does  not  change  in  the  course 

2 

of  a  simulation  run,  it  is  possible  for  groups  of  C  l  elements  to  share 

various  components.  As  was  noted  in  Chapter  II,  above,  the  design  of  the 

C  I  processes  has  emphasized  this  possibility  in  order  to  decrease  storage 

2 

requirements  and,  derivatively,  to  facilitate  Cl  input  preparation.  By 

means  of  the  procedures  described  in  Chapter  II,  it  is  possible  for  the 

user  to  create  (input)  various  Fundamental  Knowledge  information  structures 

as  named  components.  The  virtue  of  this  approach  is  that  the  user  may  then 

J  refer  to  these  components  by  name  in  creating  the  UOS's  of  the  individual 
2 

C  I  elements.  The  procedures  by  which  this  is  done  are  described  in  this 
chapter. 

A.  CREATING  UOS's 
2 

For  each  C  I  element  at  Echelons  Above  Division  (EAD)  a  unique  Under¬ 
standing  of  the  Situation  (UOS)  must  be  created.  To  initiate  this  process, 
the  individual  UOS  specifications  and  input  mujit  be  preceded  by  the  line: 

•UOS' 

This  initiates  the  proper  procedures  to  receive  UOS  specifications  and 
inputs. 

2 

To  create  the  UOS  for  a  specific  EAD  C  I  element,  the  appropriate 

information  structures  must  not  only  be  created,  but  must  also  be  linked  to 
2 

the  Cl  element.  This  linkage  is  established  by  a  reference  residing  in 
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2 

the  C  I  element's  physical  "scoreboard".  This  is  accomplished  by  the  line: 

'  <AIR/GROUND>  UNIT  =  ||  UNITID  ||  ' 

where  ||  UNITID  ||  is  the  six-digit  identity  of  the  particular  C2I  element 

whose  UOS  is  about  to  be  created  and  'AIR'  or  'GROUND'  is  specified  appro- 

2 

priately  for  that  unit.  The  reference  inserted  into  that  C  I  element's 

scoreboard  is  to  a  UOS  header  block  having  the  structure  portrayed  in 

Figure  III-l.  Note  that  none  of  the  information  elements  included  in  the 

UOS  header  are  directly  input.  The  "Unit  Identity"  element  is  filled  in 

2 

based  on  the  UNITID  specified  for  the  Cl  element. 

The  '<AIR/GROUND>  UNIT  =  ||  UNITID  || '  line  establishes  a  context  within 
which  UOS  specifications  and  inputs  are  made.  All  such  specifications  and 
inputs  are  linked  appropriately  into  the  particular  UOS  header  block 
created  by  that  line. 

All  other  information  elements  in  the  UOS  header  are  access  references 
(i.e. ,  pointers)  to  various  UOS  information  components.  Certain  of  these 
references  are  set  based  on  the  UOS  specifications  to  be  made  as  described 
in  the  following  sections.  Others  are  established  during  initialization. 
It  should  be  noted  that  the  UOS  header  block  is  the  "root"  of  the  overall 
UOS  structure  in  the  sense  that  aJ2  information  in  a  particular  UOS  is 
accessible— perhaps  via  a  chain  of  references— from  the  header  block  of 
that  UOS. 

B.  ATTACHING  NAMED  FUNDAMENTAL  KNOWLEDGE  COMPONENTS  TO  A  SPECIFIC  UOS 

Within  the  context  established  by  the  '<AIR/GROUND>  UNIT  =  j|  UNITID  H ' 
line,  named  Fundamental  Knowledge  components  created  as  described  in 
Chapter  II,  above,  may  be  "attached"  to  the  specific  UOS  by  a  sequence  of 
simple  specification  statements.  These  statements  have  the  form: 

'SET  <U0S  KEYW0RD>  =  i(  NAME  1 1  ' 

where  "<U0S  KEYW0RD>"  specifies  the  type  of  component  being  attached  and 
"j|  NAME ||  "  refers  to  a  named  component  of  the  appropriate  type.  The  com¬ 
ponents  which  may  be  attached  are,  of  course:  (1)  Standard  Operating 
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Procedures,  (2)  Updating  Thresholds  and  Flags  Directories;  (3)  Concept  of 
Operation  Directories;  (4)  Employment  Concept  Directories;  and,  (5)  Weapons 
Parameter  Directories. 

1 .  Attaching  Named  SOP  Components 

To  attach  a  named  SOP  component  to  a  particular  UOS,  the  speci¬ 
fication  statement  line  is: 

'SET  SOP  =  ||  NAME ||  ' 

The  effect  of  this  statement  is  to  insert  a  reference  to  the  named  SOP 
block  into  the  "Standard  Operating  Procedures"  information  element  of  the 
UOS.  The  SOP  component  includes  an  SOP  block  as  well  as  the  lists  of 
readiness  blocks  attached  to  it  (See  Chapter  II,  Section  A,  for  details  on 
these  components. ) 

2.  Attaching  Named  Updating  Thresholds  and  Flags  (UTF)  Components 

To  attach  a  named  UTF  component  to  a  particular  UOS,  the  specifi¬ 
cation  statement  line  is: 

'  SET  UTF  DIRECTORY  =  (|  NAME  ||  ' . 

The  effect  of  this  statement  is  to  insert  a  reference  to  the  directory  of 
the  named  UTF  component  into  the  "Updating  Thresholds  and  Flags  Directory" 
information  element  of  the  UOS.  The  UTF  component  includes  the  directory 
block  itself  together  with  the  various  UTF  blocks  attached  to  it.  (See 
Chapter  II,  Section  B,  for  details  on  these  components.) 

3.  Attaching  Named  Concepts  of  Operation  Components 

To  attach  a  named  Concept  of  Operation  component  to  a  particular 
UOS,  the  specification  statement  line  is: 

' SET  CONCEPTS  OF  OPERATION  =  ||  NAME  | ' 

The  effect  of  this  statement  is  to  insert  a  reference  to  the  directory  of 
the  named  Concepts  of  Operation  component  into  the  "Concept  of  Operation 
Directory"  information  element  of  the  UOS.  The  Concepts  of  Operation 
component  includes  the  concept  directory  block  together  with  the  lists  of 
concepts  of  operation  attached  to  it.  (See  Chapter  II,  Section  C,  for 
details  on  these  components). 
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4.  Attaching  Named  Employment  Concepts  Components 

To  attach  a  named  Employment  Concept  component  to  a  particular 
UOS,  the  specification  statement  line  is: 

'SET  EMPLOYMENT  CONCEPTS  =  ||  NAME 1 1 

The  effect  of  this  statement  is  to  insert  a  reference  to  the  directory  of 
the  named  Employment  Concepts  component  into  the  "Employment  Concept 
Directory"  information  element  of  the  UOS.  The  employment  concepts  com¬ 
ponent  includes  the  concept  directory  block  as  well  as  the  lists  of  employ¬ 
ment  concepts  attached  to  it.  (See  Chapter  II,  Section  D,  for  details  on 
these  components. ) 


5.  Attaching  Named  Weapons  Parameter  Components 

To  attach  a  named  Weapons  Parameters  component  to  a  particular 
UOS,  the  specification  statement  line  is: 

'SET  WEAPONS  PARAMETERS  =  ||  NAME||  ' 

The  effect  of  this  statement  is  to  insert  a  reference  to  the  directory  of 
the  named  Weapons  Parameters  component  into  the  "Weapons  Parameters 
Directory"  information  element  of  the  UOS.  The  Weapons  Parameters  compo¬ 
nent  includes  the  weapons  parameters  directory  block  as  well  as  the  three 
weapons  parameter  structures  attached  to  it.  (See  Chapter  II,  Section  E, 
for  details  on  these  components.) 

C.  PREPARING  A  SPECIFIC  UOS  FOR  INITIALIZATION 

Fundamental  Knowledge  inputs  are  the  major  components  input  to  an  EAD 

2 

CI  element's  UOS.  However,  referring  back  to  the  UOS  structure  portrayed 
in  Figure  1-1,  above,  it  is  apparent  that  there  are  many  other  components 
including  Situation  Data,  Operations  Data  and  Situation  Representation 
information.  These  other  components  are  prepared  by  the  simulation  itself 
during  initialization.  For  example,  Situation  Data  and  Situation  Represen¬ 
tation  information  are  prepared  by  an  initial  perception  and  information 
collection  cycle  during  which  force  elements  have  a  chance  to  "observe"  the 
force  structures  input  by  the  user.  Moreover,  Operations  Data  is  prepared 
during  the  initial  planning  by  which  EAD  C^I  elements  determine  how  to 
accomplish  the  objectives  specified  in  the  user-input  theater  operations 
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directives.  This  initial  planning  starts  with  the  theater  Cl  elements 
themselves  and  proceeds  on  down  through  the  chain-of-command  to  Army 
Groups/Fronts  and  Corps/Armies.  Certain  additional  operational  information 
needed  in  these  initialization  processes  must  be  supplied  by  the  user 
during  the  creation  of  specific  UOS's. 

Within  the  context  established  by  the  '<AIR/GROUND>  UNIT  =  || UNITID  || ' 
line,  these  additional  operational  information  elements  may  be  input  as 
described  in  the  following  sections.  This  input  processing  must  be 
preceded  by  the  line: 

'OPERATION  STRUCTURE' 

The  effect  of  tis  line  is  to  initiate  apprpriate  procedures  to  accept 
initial  operational  inputs  concerning  force  deployment  and  support 
relationships. 

1 .  Initial  Force  Deployment  Input 

Initial  force  deployment  inputs  specify  how  the  large-scale 
2 

forces  controlled. by  EAO  C  l  elements  are  to  be  configured  at  the  start  of 
the  simulation.  This  information  must  specify  the  axis  of  operations  and 
sector  width  of  the  overall  force,  the  particular  subordinate  force  ele¬ 
ments  which  are  "forward"  (i.e. ,  available  to  fill  forward  roles  in  the 
initial  operation),  and  particular  reserve  associations  among  subordinate 
force  elements,  if  any. 

a.  Axis  of  Operations  and  Sector  Width 

Axis  of  operations  and  sector  width  inputs  characterize  the 

2 

EAO  Cl  element's  area  of  operations  at  the  start  of  the  simulation.  They 

2 

may  be  changed  by  the  EAD  Cl  element  itself  in  developing  operations  to 
respond  to  its  initial  operation  directives;  however,  they  are  needed  by 
certain  initialization  procedures  which  are  performed  prior  to  the  initial 
operations  development  activities. 

1)  Axis  of  Operations 

The  axis  of  operations  of  an  EAO  C^I  element  specifies 
the  direction  in  which  his  subordinates  would  initially  advance.  It  is 
specified  in  terms  of  degrees. 


a 
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•  Range:  0  -  360° 

•  Input  Format:  Integer 

2)  Sector  Width 

2 

The  sector  width  of  an  EAO  C  I  element  specifies  the 
width  of  his  initial  area  of  operations  along  the  previously  specified  axis 
of  operations. 

•  Range:  0  -64  X10  Kilometers  (i.e. ,  0  -640  kilometers  in 

10  kilometer  increments) 
e  Input  Format:  Integer 

b.  Forward  Force  Specification  Inputs 

Among  an  EAO  C2I  element's  principal  subordinates,  some  or 

all  may  be  deployed  in  such  a  way  as  to  be  able  to  assume  forward  (or 
"contact")  roles  in  an  operation.  Since  this  may  vary  from  scenario  to 
scenario,  it  has  been  left  under  the  explicit  input  control  of  the  user. 
To  make  these  inputs,  the  user  simply  lists  the  unit  identities  of  all  sub- 
ordinates  to  the  Cl  element  which  it  is  to  regard  as  "forward  forces". 
More  specifically,  the  following  input  statement  is  used: 

F0RWAR0  FORCES  *  { )|  UNZTID  ||  ,} 

In  processing  this  statement,  the  initialization  Role  Block  for  each 
UNITID  listed  is  located  and  "marked"  as  a  forward  role;  if  an  initiali¬ 
zation  Role  Block  cannot  be  found,  an  error  condition  is  reported. 

The  order  in  which  the  subordinate  forward  force  UNITID' s 
are  listed  must  reflect  a  left-to-right  orientation  from  the  viewpoint  of 
the  EAD  C2I  element.  As  the  list  of  UNITID ' s  is  processed,  the  first 
UNITID  will  be  established  as  the  "left-most"  forward  role,  the  second 
UNITID  will  be  established  immediately  to  the  right  of  the  "left-most"  for¬ 
ward  role,  and  so  on,  down  to  the  last  UNITID  which  will  be  established  as 

the  "right-most"  forward  role.  "Left"  and  "right"  reflect  the  point  of 
2 

view  of  the  EAD  C  l  element  as  it  faces  the  opposing  forces.  Thus,  for  an 
EAD  Cl  element  facing  due  East,  the  "northern-most"  forward  subordinate 
would  be  the  "left-most"  (and  hence  would  be  input  first);  the  "southern¬ 
most"  forward  subordinate  would  be  the  "right-most"  (and  hence  input  last). 
By  contrast,  for  an  EAD  Cl  element  facing  due  West,  the  left-to-right 
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orientation  would  be  exactly  reversed  (i.e. ,  the  "norther-most"  would  be 
the  "right-most"). 

c.  Reserve  Relationship  Inputs 

The  last  initial  deployment  inputs  enable  the  user  to 
specify  that  a  particular  (non-forward)  force  element  is  to  serve  initially 
as  a  dedicated  reserve  to  a  forward  force  element.  These  inputs  are 
optional— the  user  need  not  specify  any  initial  reserve  associations.  If 
he  does,  statemens  of  the  following  form  must  be  used: 

||  RESERVE  UNITIDll  IS  RESERVE  TO  ((SUPPORTED  UNITI0||  . 

As  many  statements  of  this  form  may  be  used  as  required  to  establish  the 
desired  relationships.  Each  statement  is  processed  by  locating  the  initia¬ 
lization  Role  Blocks  for  the  units  indicated  and  linking  them  by  means  of 
Reserve  Associate  Pointers.  If  one  of  the  units  cannot  be  found  on  are  not 
deployed  appropriately  (i.e.,  reserve  unit  in  non-forward  role,  supported 
unit  in  forward  role),  an  error  condition  is  reported. 

2.  Support  Relationships  Input 

Besides  the  subordinate  forces  it  controls,  an  EAD  C2I  element 
may  be  able  to  call  on  several  other  force  elements  for  support— air  force 
EAD  Cl  elements,  its  own  combat  source  support  complex,  and  nuclear  or 
chemical  delivery  agencies.  Like  the  chain-of-command  structure,  these  sup¬ 
port  relationships  are  left  under  the  explicit  control  of  the  user  via 
inputs.  Within  the  model,  such  relationships  are  represented  by  Force  Ele¬ 
ment  Directory  Entry  Blocks  as  shown  in  Figure  III-2.  These  blocks  are 

input  by  the  user  and  placed  on  a  list  of  support  forces  accessible  through 

2 

the  Force  Directory  component  of  the  EAD  C  I  element's  UOS.  (See  the  Soft¬ 
ware  Description,  Volume  II,  Chapter  II,  Section  F  for  further  details.) 

Within  the  context  established  by  the  '<AIR/GROUND>  UNIT  = 
UNITID  '  and  'OPERATION  STRUCTURE'  lines,  the  creation  of  an  individual 
support  relationship  is  initiated  by  the  line: 

'SUPPORT' 

This  line  initiates  procedures  to  receive  inputs  to  a  supporting  Force 
Element  Directory  Entry  Block  as  will  now  be  described. 


CWi 
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a.  Support  Category 

A  code  indicating  the  particular  type  of  support  provided  to 
the  C2I  element.  At  present,  this  may  be:  (1)  air  support,  (2)  nuclear 
weapons  delivery  support,  (3)  chemical  weapons  delivery  support,  or,  (4) 
service  support. 

•  Range:  N/A 

•  Input  Format:  AIR-SPT/NUC-WPNS-SPT/ 

CHM-WPNS-SPT/SVC-SPT 

b.  Supported  Force  Element  Identity 

The  unit  identity  of  the  particular  force  element  supported 
by  the  force  element  characterized  by  the  directory  entry  block. 

§  Range:  N/A 

•  Input  Format:  6-digit  Unit  Identity 

c.  Force  Element  Identity 

The  unit  identity  of  the  force  element  characterized  by  the 
directory  entry  block. 

•  Range:  N/A 

e  Input  Format:  6-digit  Unit  Identity 

D.  OPTIONAL  UPS  SPECIFICATIONS 

Still  operating  within  the  context  specified  by  the  line  '<AIR/GROUND> 
UNIT  *  ||UNITID||  ',  the  user  may  optionally  specify  two  other  UOS  compo¬ 
nents  by  inputs:  the  Weapons  Management  component  and/or  the  Readiness  Man¬ 
agement  Component.  Weapons  Management  inputs  may  be  utilized  to  authorize 
specific  packages  of  nuclear  or  chemical  weapons  to  the  EAO  C  I  element 
whose  UOS  is  being  specified.  Readiness  management  inputs  may  be  used  to 
put  the  EAD  C2I  element  in  a  higher  readiness  state  than  state  "0",  the 
default  state. 

1 .  Optional  Weapons  Management  Input 

The  Weapons  Management  component  of  the  UOS  was  discussed  in  the 
Software  Description,  Volume  II,  Chapter  II,  Section  N.  From  an  input 
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poi£t  of  view,  the  only  elements  of  interest  to  the  user  would  be  the  pack¬ 
ages  of  authorized  nuclear  or  chemical  weapons.  To  input  either  or  both 
types  of  packages,  the  user  must  first  use  the  statement 

'WEAPONS  MANAGEMENT' 

This  creates  a  Weapons  Management  Block  having  the  form  shown  in  Figure 
III-3.  As  can  be  seen,  there  are  no  direct  inputs  to  this  block;  however, 
the  "oldest  Nuclear  Employment  Package"  and  "oldest  Chemical  Employment 
Package"  pointers  provide  points  of  "attachment"  for  user-specified  weapons 
packages. 

To  input  a  particular  nuclear/chemical  weapons  package,  the  user 
must  then  use  the  statement 

' <NUCLEAR/CHEMICAL>  PACKAGE ' . 

This  initiates  procedures  to  receive  the  given  type  of  package  inputs  and 
also  specifies  which  of  the  package  pointers  in  the  Weapons  Managment  Block 
should  be  used  to  reference  the  input  package.  The  package  inputs  them¬ 
selves  are  used  to  build  an  Employment  Package  Block  having  the  form  pre¬ 
sented  in  Figure  III-4.  Its  input  will  now  be  discussed. 

a.  Employer  Information 

The  unit  identity  of  the  EAD  C2I  element  which  is  authorized 
to  employ  the  weapons  specified  in  the  package. 

•  Range:  N/A 

e  Input  Format:  6-digit  Unit  Identity 

b.  Weapons  Information 

These  two  information  elements  specify  the  type  and  quantity 
of  weapons  authorized  for  employment.  Weapons  type  is  implicit  in  the  pack¬ 
age  designator  format  described  above.  Weapons  quantity  represents  the 
maximum  amount  of  weapons  authorized  for  employment.  It  range  and  format 
are  as  follows: 

e  Range:  0  -  262,000  appropriate  units 

(sorties,  kilotons,  or  tons) 

e  Input  Format:  Integer 

c.  Employment  Information 

These  two  information  elements  specify  the  conditions  under 

which  the  specified  weapons  are  authorized  for  employment. 
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EMPLOYMENT  PACKAGE  BLOCK 

(PKGBLK) 


EMPLOYER  INFORMATION 
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UNITID 

18 

WEAPONS  INFORMATION 

WEAPONS  TYPE 

WPNTYP 

3 

WEAPONS  QUANTITY 

WPNQUN 

18 

EMPLOYMENT  INFORMATION 

JUSTIFICATION 

1 

wm 

UTILIZATION  INTERVAL 
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m 

EXPIRATION  TIME 

18 
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1)  Justification 

The  justification  of  an  employment  package  delimits  the 
situations  under  which  the  specified  weapons  may  be  employed.  Possible 
situations  are:  (1)  Critical  Forward  Operation  Progress,  (2)  Critical 
Forward  Operation  Failure,  (3)  Critical  Kernel  Operation  Progress,  (4) 
Critical  Kernel  Operation  Failure,  (5)  Critical  Strength,  (6)  Critical  Unit 
Balance,  (7)  Critical  Nuclear  Threat,  and  (8)  Critical  Chemical  Threat. 
Any  or  all  of  these  may  be  flagged  as  acceptable  conditions  for  employment. 

•  Range:  N/A 

t  Input  Format:  {<FWD  PROGRESS/FORWARD  FAIL/ 

KERNEL  PROGRESS/KERNEL  FAIL/ 

STRENGTH/UNIT  BALANCE/ 

NUCLEAR  THREAT/CHEMICAL  THREAT> , } 

2)  Utilization  Interval 

The  time  interval  within  which  the  weapons  specified  in 
the  package  are  authorized  for  employment.  It  is  measured  from  the  time  at 
which  the  simulation  starts  (i.e. ,  minutes). 

•  Range:  0  -  4000  hours 

•  Input  Format:  Integer 

2.  Optional  Readiness  Management  Inputs 


The  Readiness  Management  component  of  an  EAD  C  l  element  s  UOS 
was  discussed  in  the  Software  Description,  Volume  II,  Chapter  II,  Section 
0.  From  an  input  perspective,  the  user  may  wish  to  specify  an  initial 
directed  nuclear  or  chemical  readiness  state  higher  than  state  0  (which  is 
the  default  state  if  no  inputs  are  made).  To  initiate  such  inputs,  the 
line: 

'READINESS  MANAGEMENT' 

must  be  used.  This  creates  a  Readiness  Management  Block  having  the  form 
presented  in  Figure  III-5.  As  can  be  seen,  the  inputs  to  this  block  are 
the  Directed  Nuclear  Readiness  State  (DNUKST)  and  the  Directed  Chemical 
Readiness  State  (DCHMST).  These  are  input  by  the  lines: 

'NUCLEAR  READINESS  =  i' 

'CHEMICAL  READINESS  =  j' 
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READINESS  MANAGEMENT  BLOCK 


(RMGBLK) 


NUCLEAR  READINESS  MANAGEMENT  INFORMATION 


DIRECTED  NUCLEAR  READINESS  STATE 


CHEMICAL  READINESS  MANAGEMENT  INFORMATION 


DIRECTED  CHEMICAL  READINESS  STATE 


DNUKST 


DCHMST 


Figure  III-5.  Readiness  Management  Block  Structure 
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The  specific  values  input  should  correspond  to  the  particular  Readiness 

2 

Block  by  which  the  user  desires  the  EAO  C  I  element  to  operate  initially. 
(See  Chapter  II,  Section  A.  1,  above,  for  discussion  of  Readiness  Block 
inputs. ) 
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CHAPTER  IV 
DIRECTIVE  INPUTS 


2 

Although  the  basic  Cl  inputs  involve  UOS  elements,  certain  other 

2 

types  of  inputs  with  impacts  on  C  I  processes  are  possible.  In  particular, 

it  is  possible  for  the  user  to  “send"  various  types  of  directives  to  EAD 

2  2 
C  I  elements.  These  inputs  allow  the  user  to  influence  C  I  behavior 

"externally".  Operations  directives,  readiness  directives,  and  weapons 

employment  directives  may  be  input  as  described  below. 

In  preparing  directive  inputs,  the  user  should  adopt  the  perspective 

2 

of  an  echelon  of  command  superior  to  the  theater  level  C  I  elements  (i.e. , 

"Natural  Command  Authorities").  In  general,  such  input  directives  should 

2 

also  be  sent  to  (or  "through")  the  theater  level  C  I  elements.  This  allows 
2 

the  C  I  processes  to  properly  accomodate  the  new  directive.  It  would,  for 

example,  be  possible  to  send  a  new  operations  directive  directly  to  a  corps 

2  2 
level  C  I  element.  However,  the  parent  Army  Group  Cl  element  would  not  be 

aware  of  this  Imposed  change  in  its  subordinate's  operation.  It  would 

accordingly  continue  its  own  overall  operation  under  the  mistaken  assump~ 

tion  that  the  subordinate  corps  was  still  behaving  as  directed.  It  is 

difficult  to  predict  the  possible  outcomes  of  such  a  situation. 


A.  CREATING  A  MESSAGE  TO  CARRY  THE  DIRECTIVE  INFORMATION 


The  first  step  in  inputing  a  specific  directive  is  to  create  a  message 
block  to  "carry"  the  directive  information.  A  message  block  has  the 
structure  portrayed  in  Figure  IV- 1.  To  initiate  the  message  creation 
process,  the  line: 

'CREATE  MESSAGE' 

must  precede  all  specific  message  block  inputs.  These  information  inputs 
will  now  be  discussed. 

1.  Sender  Information 

Sender  information  identifies  the  sender  of  the  message.  In 
consonance  with  the  Introductory  comments  to  this  chapter,  user  input 


IV- 1 
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directives  should  be  regarded  as  sent  by  a  command  element  superior  to  the 
theater.  Hence,  "Sender  Identity"  need  not  be  input  for  user  input 
directives. 

2.  Message  Characteristics 

These  information  elements  represent  characteristics  of  the 

message. 

a.  Message  Security 

The  level  of  security  with  which  the  directive  is  to  be 

transmi tted 

•  Range:  0  -  3  (3  ~  highest  level) 

•  Input  Format:'  Integer 

b.  Message  Priority 

The  priority  with  which  the  directive  is  to  be  transmitted 
t  Range:  0  -  7  (7  =  highest  priority) 

•  Input  Format:  Integer 

c.  Message  Class,  Content.  Form  and  Kind 

Integer  codes  representing  aspects  of  the  information 
carried  by  tfe  message.  For  user  input  directives,  message  content 
(MSGCON)  should  be  entered  as  1  (*di recti ve  content  type  code).  Class, 
form  and  kind  need  not  be  input. 

d.  Message  Time 

The  time  at  which  the  message  is  to  be  sent,  input  in  hours 
after  the  "starting"  time  of  the  run. 

•  Range:  0  -  4000  hours 

•  Input  Format:  Integer 

B.  CREATING  DIRECTIVE  CONTENTS 


The  message  block  provides  the  vehicle  to  carry  the  directive  informa¬ 
tion  or  content.  The  content  itself  is  contained  in  a  directive  header 
block  with  the  structure  portrayed  in  Figure  IV-2.  (See  the  Software 
Description,  Volume  II,  Chapter  III,  Section  B,  for  further  discussion  of 
directives.)  Three  different  types  of  content  are  possible  corresponding 


DIRECTIVE  HEADER 


(DIRHDR) 


BASIC  DIRECTIVE  INFORMATION 

DIRECTIVE  TYPE  DIRTYP  3 

DIRECTED  FORCE  ELEMENT  UNITID  18 


READINESS  DIRECTIVE  INFORMATION 

DIRECTED  READINESS  TYPE  RDYTYP  3 

DIRECTED  READINESS  STATE  RDYSTA  3 


WEAPONS  EMPLOYMENT  DIRECTIVE 

I  DIRECTED  WEAPONS  TYPE  '  I  WPNTYP  I  3 


Figure  IV-2.  Directive  Header  Structure 
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to  the  type  of  directive  being  input  (operations,  readiness,  or  weapons 
employment).  The  line: 

'DIRECTIVE  CONTENT' 

initiates  the  creation  of  a  specific  directive  content.  Since  all  direc¬ 
tive  contents  contain  the  identity  of  the  directed  force  element,  this  may 
now  be  input  (in  6-digit  Unit  Identity  format)  by  the  line: 

' FORCE  ELEMENT  =  UNIT  IDENTITY  1 . 

All  directive  contents  also  contain  an  integer  code  representing  the  type 
directive.  This  is  input  next  by  means  of  the  appropriate  line: 

'OPERATION  DIRECTIVE',  or 
'READINESS  DIRECTIVE' ,  or 
'WEAPONS  DIRECTIVE'. 

Besides  implicitly  setting  the  directive  type  in  the  directive  header,  this 
line  invokes  the  proper  routine  to  receive  the  type-dependent  inputs. 
These  will  be  discussed  individually  in  Sections  1-3,  below. 

1.  Creating  Operation  Directive  Contents 

An  operation  directive  contains  two  basic  components:  (1)  an 
operation  order  block  having  the  structure  presented  in  Figure  IV-3,  and, 
(2)  a  resource  allocation  block  having  the  structure  presented  in  Figure 
IV-4.  These  two  blocks  are  created  separately  and  are  implicitly  linked 
into  the  directive  header  structure. 

a.  Creating  Operation  Orders 

The  creation  of  a  specific  operation  order  as  a  directive 
component  is  initiated  by  the  line: 

'OPERATION  ORDER' 

The  operation  order  block  has  been  designed  to  be  usable  by  all  INWARS 
entities.  As  a  consequence,  certain  of  its  information  elements  are  not 
requi red  by  EAD  C  I  elements;  this  accounts  for  the  hatched  information 
elements  in  Figure  IV-3.  The  remaining  direct-input  information  elements 
will  now  be  discussed. 

1)  Operation  Information 

These  Information  elements  characterize  the  directed 

operation  in  terms  of  mission  and  objective.  (Role  specifications  are  not 
2 

required  by  EAD  C  l  elements.) 


“■c.  *: 
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OPERATION  ORDER  BLOCK 


(OPORD) 


OPERATION 

MISSION 

MISCOD 

5 

OBJECTIVE 

HEXOBJ 
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|  DISPOSITION  CONTROL 
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BH 
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6 

|  OPERATION  CONTROL 

COMPLETION  TIME 

TIME 
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EXECLT 

HON  CONTROL 

mm 

— 

OPORD  BLOCK  ADMINISTRATION 
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a)  Mission 

An  integer  code  designating  the  particular  type  of 
mission  to  be  accomplished  in  responding  to  the  operation  order. 

•  Range:  0-63 

e  Input  Format:  Integer 

b)  Objective 

The  specific  9.45  km  hexagon  designated  as  the 
objective  for  the  directed  operation, 
e  Range:  N/A 

e  Input  Format:  Hex  Address 

2)  Disposition  Control  Information 

These  information  elements  constrain  the  disposition  of 
the  force  conducting  the  directed  operation. 

a)  Axis  of  Operations 

An  angle  specification  of  axis  which  controls  the 
orientation  of  the  force  conducting  the  operation  vis-a-vis  the  enemy 

forces  it  faces. 

e  Range:  0  -  360  degress 

e  Input  Format:  Integer 

b)  Sector  Width 

A  width  expressed  in  hexes  to  be  covered  (or, 
approximately,  kilometers  to  be  covered  x  10)  which  controls  the  lateral 
dispersion  of  the  force  conducting  the  operation. 

e  Range:  0-63  hexes  (approximately 

0  -  630  kilometers) 
e  Input  Format:  Integer 

3)  Operation  Control 

This  Information  element— completion  time— controls  the 
execution  of  the  operation  by  specifying  a  particular  time  at  which  the 
operation  should  be  complete  (i.e.,  at  which  the  force  element  conducting 
the  operation  should  be  at  the  specified  objective).  Expressed  in  terms  of 
hours  after  the  initial  "start"  time  of  the  run. 
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•  Range:  0  -  4000  hours 

•  Input  Format:  Integer 

b.  Creating  Rescource  Allocation  Blocks 

The  creation  of  a  specific  resource  allocation  block  as  a 
directive  comppnent  is  initiated  by  the  line: 

•RESOURCE  ALLOCATION1 


Referring  to  Figure  IV-4,  it  will  be  noted  that  there  are  two  basic  types 
of  information  in  the  allocation  block:  (1)  the  allocated  resources  (of 
the  various  types)  with  which  the  force  conducting  the  directed  operation 
must  operate,  and,  (2)  "allocate-resource"  flags  (for  the  various  resource 
types)  which  control  the  response  of  the  directed  force  element  to  the  new 
allocation  guidance. 

1)  Allocated  Resources 

These  information  elements  characterize  how  much  of 
each  type  of  resource  is  allocated  to  the  directed  force  element  for  use  in 
conducting  the  directed  operation. 


Ranges: 

CAS  &  Interdiction: 
Nuclear  Weapons: 
Chemical  Weapons: 
Supplies: 
Replacements: 


0  -  4000  sorties/day 
0  -  262,000  nuclear  weapons  units 
0  -  262,000  chemical  weapons  units 
0  -  262,000  tons/day 
0  -  262,000  strength  units/day 


•  Input  Format:  Integer 

2)  "Allocate-Resource"  Flags 

These  information  elements  indicate  whether  or  not  the 
directed  force  element  should  adjust  its  resource  allocations  to  conform  to 
the  new  allocated  resource  specifications.  It  should  be  set  to  1  for  any 
resource  type  for  which  allocation  guidance  is  specified 

e  Range:  0,1  (1  =  adjust  resource  allocations  for  the 

corresponding  resource  type) 

•  Input  Format:  Integer 
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2.  Creating  Readiness  Directive  Contents 

Compared  to  operation  directives,  readiness  directives  have  a 
very  simple  structure.  Referring  to  Figure  IV-2,  it  will  be  noted  that 
only  two  information  elements  need  be  input  to  create  a  readiness 
directive. 

a.  Directed  Readiness  Type 

Indicates  whether  the  readiness  directive  concerns  nuclear 
or  chemical  readiness. 

e  Range:  N/A 

e  Input  Format:  NUCLEAR/CHEMICAL 

b.  Directed  Readiness  State 

Specifies  the  lowest  readiness  state  (of  the  directed  type) 
at  which  the  directed  force  element  should  operate. 

e  Range:  0  -  7  (7  =  highest  readiness  state) 
a  Input  Format:  Integer 

3.  Creating  Weapons  Employment  Directive  Contexts 

A  weapons  employment  directive  header  contains  an  indication  of 
the  type  of  weapons  whose  employment  is  directive;  it  also  contains  a 
reference  to  a  specific  package  of  weapons  whose  employment  is  authorized. 
The  directed  weapons  type  is  first  entered;  then  the  authorized  package 
block  is  created. 

a.  Directed  Weapons  Type 

An  indicator  of  the  type  of  weapons— interdiction,  nuclear, 
or  chemical— whose  employment  is  directed, 
e  Range:  N/A 

e  Input  Format:  INT/NUC/CHM 

b.  Creating  Employment  Packages 

An  employment  package  block  has  the  structure  portrayed  in 
Figure  IV-5.  Created  in  the  context  of  a  weapons  employment  directive,  it 
is  implicitly  linked  into  the  directive  header.  Its  Information  elements 
will  now  be  discussed. 

1)  Employer  Information 

The  unit  Identity  of  the  EAD  C*I  element  which  is 
authorized  to  employ  the  weapons  specified  in  the  package.  Note  that  the 
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employer  may  be  different  from--and  at  a  lower  echelon  of  command  than— the 
directed  force  element  specified  in  the  directive  header. 

•  Range:  N/A 

•  Input  Format:  6-digit  Unit  Identity 
2)  Weapons  Information 

These  two  information  elements  specify  the  type  and 
quantity  of  weapons  authorized  for  employment.  Weapons  type  is  input  in 
the  same  format  as  described  above.  Weapons  quantity  represents  the 
maximum  amount  of  weapons  authorized  for  employment.  Its  range  and  format 
are  as  follows: 

•  Range:  0  -  262,000  appropriate  units 

(sorties,  kilotons,  or  tons) 


Input  Format:  Integer 
3)  Employment  Information 

These  two  information  elements  specify  the  conditions 


under  which  the  specified  weapons  are  authorized  for  employment. 


a)  Justification 

The  justification  of  an  employment  package 
delimits  the  situations  under  which  the  specified  weapons  may  be  employed. 
Possible  situations  are:  (1)  Critical  Forward  Operation  Progress,  (2) 
Critical  Forward  Operation  Failure,  (3)  Critical  Kernel  Operation  Progress, 
(4)  Critical  Kernel  Operation  Failure,  (5)  Critical  Strength,  (6)  Critical 
Unit  Balance,  (7)  Critical  Nuclear  Threat,  and  (8)  Critical  Chemical 
Threat.  Any  or  all  of  these  may  be  flagged  an  acceptable  condition  for 
employment 

•  Range:  N/A 

•  Input  Format:  {<FWD  PROGRESS/FORWARD  FAIL/ 

KERNEL  PROGRESS/KERNEL  FAIL/ 

STRENGTH/UNIT  BALANCE/ 

NUCLEAR  THREAT/CHEMICAL  THREAT> , } 
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b)  Utilization  Interval 

The  time  interval  within  which  the  weapons  speci¬ 
fied  in  the  package  are  authorized  for  employment.  It  is  measured  from  the 
time  at  which  the  specified  employer  receives  the  employment  directive. 

•  Range:  0  -  4000  hours 

•  Input  Format:  Integer 


